1. 程式人生 > >SQL Server 海量數據查詢代碼優化以及建議

SQL Server 海量數據查詢代碼優化以及建議

觸發 導出 後者 between mem 存儲 ediff 新建 t_sql

1.應盡量避免在 where 子句中對字段進行 null 值推斷,否則將導致引擎放棄使用索引而進
行全表掃描,如:
select id from t where num is null


能夠在num 上設置默認值0 ,確保表中num 列沒有null 值,然後這樣查詢:
select id from t where num=0



2.應盡量避免在 where 子句中使用!=或<>操作符,否則將引擎放棄使用索引而進行全表掃
描。優化器將無法通過索引來確定將要命中的行數, 因此須要搜索該表的全部行。


3.應盡量避免在 where 子句中使用 or 來連接條件。否則將導致引擎放棄使用索引而進行
全表掃描,如:
select id from t where num=10 or num=20

能夠這樣查詢:
select id from t where num=10
union all
select id from t where num=20


4.in 和 not in 也要慎用,由於IN 會使系統無法使用索引,而僅僅能直接搜索表中的數據。如:
select id from t where num in(1,2,3)

對於連續的數值。能用 between 就不要用 in 了:
select id from t where num between 1 and 3


5.盡量避免在索引過的字符數據中,使用非打頭字母搜索。

這也使得引擎無法利用索引。


見例如以下樣例:
SELECT * FROM T1 WHERE NAME LIKE ‘%L%’
SELECT * FROM T1 WHERE SUBSTING(NAME,2,1)=’L’
SELECT * FROM T1 WHERE NAME LIKE ‘L%’
即使 NAME 字段建有索引。前兩個查詢依舊無法利用索引完畢加快操作,引擎不得不正確全
表全部數據逐條操作來完畢任務。而第三個查詢可以使用索引來加快操作。



6.必要時強制查詢優化器使用某個索引。如在 where 子句中使用參數,也會導致全表掃描。
由於 SQL 僅僅有在執行時才會解析局部變量,但優化程序不能將訪問計劃的選擇推遲到執行
時;它必須在編譯時進行選擇。然 而。假設在編譯時建立訪問計劃,變量的值還是未知的。
因而無法作為索引選擇的輸入項。如以下語句將進行全表掃描:
select id from t where [email protected]

/* */
能夠改為強制查詢使用索引:
select id from t with(index(索引名)) where [email protected]

7.應盡量避免在 where 子句中對字段進行表達式操作,這將導致引擎放棄使用索引而進行
全表掃描。如:
SELECT * FROM T1 WHERE F1/2=100
應改為:
SELECT * FROM T1 WHERE F1=100*2
SELECT * FROM RECORD WHERE SUBSTRING(CARD_NO,1,4)=’5378’
應改為:
SELECT * FROM RECORD WHERE CARD_NO LIKE ‘5378%’
SELECT member_number, first_name, last_name FROM members
WHERE DATEDIFF(yy,datofbirth,GETDATE()) > 21

應改為:
SELECT member_number, first_name, last_name FROM members
WHERE dateofbirth < DATEADD(yy,-21,GETDATE())
即:不論什麽對列的操作都將導致表掃描,它包含數據庫函數、計算表達式等等,查詢時要盡可
能將操作移至等號右邊。




8.應盡量避免在where 子句中對字段進行函數操作,這將導致引擎放棄使用索引而進行全表
掃描。如:
select id from t where substring(name,1,3)=‘abc‘--name 以abc 開頭的id
select id from t where datediff(day,createdate,‘2005-11-30‘)=0-- ‘2005-11-30 ’生成的id
應改為:
select id from t where name like ‘abc%‘
select id from t where createdate>=‘2005-11-30‘ and createdate<‘2005-12-1‘

9.不要在 where 子句中的“= ”左邊進行函數、算術運算或其它表達式運算,否則系統將可
能無法正確使用索引。

10.在使用索引字段作為條件時。假設該索引是復合索引。那麽必須使用到該索引中的第一
個字段作為條件時才幹保證系統使用該索引,否則該索引將不會被使用。而且應盡可能的讓
字段順序與索引順序相一致。


11.非常多時候用 exists 是一個好的選擇:
select num from a where num in(select num from b)
用以下的語句替換:
select num from a where exists(select 1 from b where num=a.num)
SELECT SUM(T1.C1)FROM T1 WHERE(
(SELECT COUNT(*)FROM T2 WHERE T2.C2=T1.C2>0)
SELECT SUM(T1.C1) FROM T1WHERE EXISTS(
SELECT * FROM T2 WHERE T2.C2=T1.C2)
兩者產生同樣的結果,可是後者的效率顯然要高於前者。由於後者不會產生大量鎖定的表掃
描或是索引掃描。


假設你想校驗表裏是否存在某條紀錄,不要用count(*)那樣效率非常低。並且浪費server資源。


能夠用EXISTS 取代。如:
IF (SELECT COUNT(*) FROM table_name WHERE column_name = ‘xxx‘)
能夠寫成:
IF EXISTS (SELECT * FROM table_name WHERE column_name = ‘xxx‘)
常常須要寫一個T_SQL 語句比較一個父結果集和子結果集。從而找到是否存在在父結果集中
有而在子結果集中沒有的記錄,如:
SELECT a.hdr_key FROM hdr_tbl a---- tbl a 表示tbl 用別名a 取代
WHERE NOT EXISTS (SELECT * FROM dtl_tbl b WHERE a.hdr_key = b.hdr_key)
SELECT a.hdr_key FROM hdr_tbl a
LEFT JOIN dtl_tbl b ON a.hdr_key = b.hdr_key WHERE b.hdr_key IS NULL
SELECT hdr_key FROM hdr_tbl
WHERE hdr_key NOT IN (SELECT hdr_key FROM dtl_tbl)
三種寫法都能夠得到相同正確的結果,可是效率依次減少。


12.盡量使用表變量來取代暫時表。假設表變量包括大量數據,請註意索引很有限(僅僅有
主鍵索引)。


13.避免頻繁創建和刪除暫時表。以降低系統表資源的消耗。




14.暫時表並非不可使用。適當地使用它們能夠使某些例程更有效,比如。當須要反復引
用大型表或經常使用表中的某個數據集時。可是。對於一次性事件,最好使用導出表。

15.在新建暫時表時。假設一次性插入數據量非常大,那麽能夠使用 select into 取代 create
table ,避免造成大量 log ,以提快速度;假設數據量不大。為了緩和系統表的資源,應先
create table。然後insert。


16.假設使用到了暫時表,在存儲過程的最後務必將全部的暫時表顯式刪除,先 truncate
table ,然後 drop table ,這樣能夠避免系統表的較長時間鎖定。


17.在全部的存儲過程和觸發器的開始處設置 SET NOCOUNT ON ,在結束時設置 SET
NOCOUNT OFF 。

無需在運行存儲過程和觸發器的每一個語句後向client發送 DONE_IN_PROC
消息。




18.盡量避免大事務操作。提高系統並發能力。

19.盡量避免向client返回大數據量,若數據量過大,應該考慮對應需求是否合理。

20. 避免使用不兼容的數據類型。比如float 和int、char 和varchar 、binary 和varbinary 是不
兼容的。

數據類型的不兼容可能使優化器無法運行一些本來能夠進行的優化操作。比如:
SELECT name FROM employee WHERE salary > 60000
在這條語句中,如salary 字段是money 型的,則優化器非常難對其進行優化, 由於60000 是個整型
數。我們應當在編程時將整型轉化成為錢幣型,而不要等到執行時轉化。




21.充分利用連接條件。在某種情況下。兩個表之間可能不僅僅一個的連接條件。這時在 WHERE
子句中將連接條件完整的寫上,有可能大大提高查詢速度。
例:
SELECT SUM(A.AMOUNT) FROM ACCOUNT A,CARD B WHERE A.CARD_NO = B.CARD_NO
SELECT SUM(A.AMOUNT) FROM ACCOUNT A,CARD B WHERE A.CARD_NO = B.CARD_NO AND
A.ACCOUNT_NO=B.ACCOUNT_NO
第二句將比第一句運行快得多。


22、使用視圖加速查詢
把表的一個子集進行排序並創建視圖,有時能加速查詢。它有助於避免多重排序 操作。而
且在其它方面還能簡化優化器的工作。

比如:
SELECT cust.name,rcvbles.balance,??other columns
FROM cust。rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
AND cust.postcode>“98000”
ORDER BY cust.name
假設這個查詢要被運行多次而不止一次,能夠把全部未付款的客戶找出來放在一個視圖中,
並按客戶的名字進行排序:
CREATE VIEW DBO.V_CUST_RCVLBES
AS
SELECT cust.name,rcvbles.balance,??other columns
FROM cust。rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
ORDER BY cust.name

然後以以下的方式在視圖中查詢:
SELECT * FROM V_CUST_RCVLBES
WHERE postcode>“98000”
視圖中的行要比主表中的行少,並且物理順序就是所要求的順序,降低了磁盤I/O,所以查
詢工作量能夠得到大幅降低。




23、能用DISTINCT 的就不用GROUP BY
SELECT OrderID FROM Details WHERE UnitPrice > 10 GROUP BY OrderID
可改為:
SELECT DISTINCT OrderID FROM Details WHERE UnitPrice > 10

24.能用UNION ALL 就不要用UNION
UNION ALL 不運行SELECT DISTINCT 函數,這樣就會降低非常多不必要的資源


25.盡量不要用SELECT INTO 語句。


SELECT INOT 語句會導致表鎖定。阻止其它用戶訪問該表。


上面我們提到的是一些主要的提高查詢速度的註意事項,可是在很多其它的情況下,往往須要重復
試驗比較不同的語句以得到最佳方案。最好的方法當然是測試,看實現 同樣功能的SQL 語
句哪個運行時間最少。可是數據庫中假設數據量非常少,是比較不出來的。這時能夠用查看執
行計劃,即:把實現同樣功能的多條SQL 語句考到 查詢分析器,按CTRL+L 看查所利用的索
引,表掃描次數(這兩個對性能影響最大),整體上看詢成本百分比就可以。



SQL Server 海量數據查詢代碼優化以及建議