語句執行效率說明(僅供參考)

之前收集的一些資料僅供參考, 不一定完全正確... 有錯誤望指正

1、操作符號： NOT IN操作符
此操作是強列推薦不使用的，因爲它不能應用表的索引。推薦方案：用NOT EXISTS 或（外連接+判斷爲空）方案代替 "IS NULL", "<>", "!=", "!>", "!<", "NOT", "NOT EXISTS", "NOT IN", "NOT LIKE", "LIKE '%500'"，因爲他們不走索引全是表掃描。NOT IN會多次掃描表，使用EXISTS、NOT EXISTS、IN、LEFT OUTER JOIN來替代，特別是左連接,而Exists比IN更快，最慢的是NOT操作. 如果列的值含有空，以前它的索引不起作用，現在2000的優化器能夠處理了。相同的是IS NULL，"NOT", "NOT EXISTS", "NOT IN"能優化她，而"<>"等還是不能優化，用不到索引。

2、注意union和union all的區別。union比union all多做了一步distinct操作。能用union all的情況下儘量不用union。

3、查詢時儘量不要返回不需要的行、列。另外在多表連接查詢時，儘量改成連接查詢，少用子查詢。。

4、儘量少用視圖，它的效率低。對視圖操作比直接對錶操作慢,可以用存儲過程來代替它。特別的是不要用視圖嵌套,嵌套視圖增加了尋找原始資料的難度。
我們看視圖的本質：它是存放在服務器上的被優化好了的已經產生了查詢規劃的SQL。對單個表檢索數據時，不要使用指向多個表的視圖，
直接從表檢索或者僅僅包含這個表的視圖上讀，否則增加了不必要的開銷,查詢受到干擾.爲了加快視圖的查詢，MsSQL增加了視圖索引的功能。

5、創建合理的索引，對於插入或者修改比較頻繁的表，儘量慎用索引。因爲如果表中存在索引，插入和修改時也會引起全表掃描。
索引一般使用於where後經常用作條件的字段上。

6、在表中定義字段或者存儲過程、函數中定義參數時，將參數的大小設置爲合適即可，勿設置太大。這樣開銷很大。

7、Between在某些時候比IN速度更快,Between能夠更快地根據索引找到範圍。用查詢優化器可見到差別。
select * from chineseresume where title in ('男','女')
Select * from chineseresume where between '男' and '女'是一樣的。由於in會在比較多次，所以有時會慢些。

8、在必要是對全局或者局部臨時表創建索引，有時能夠提高速度，但不是一定會這樣，因爲索引也耗費大量的資源。他的創建同是實際表一樣。

9、WHERE後面的條件順序影響
WHERE子句後面的條件順序對大數據量表的查詢會產生直接的影響，如
Select * from zl_yhjbqk where dy_dj = '1KV以下' and xh_bz=1
Select * from zl_yhjbqk where xh_bz=1 and dy_dj = '1KV以下'
以上兩個SQL中dy_dj（電壓等級）及xh_bz（銷戶標誌）兩個字段都沒進行索引，所以執行的時候都是全表掃描，如果dy_dj = '1KV以下'條件在記錄集內比率爲99%，而xh_bz=1的比率只爲0.5%，在進行第一條SQL的時候99%條記錄都進行dy_dj及xh_bz的比較，而在進行第二條SQL的時候0.5%條記錄都進行dy_dj及xh_bz的比較，以此可以得出第二條SQL的CPU佔用率明顯比第一條低。所以儘量將範圍小的條件放在前面。。

10、用OR的字句可以分解成多個查詢，並且通過UNION 連接多個查詢。他們的速度只同是否使用索引有關,如果查詢需要用到聯合索引，用 UNION all執行的效率更高.多個OR的字句沒有用到索引，改寫成UNION的形式再試圖與索引匹配。一個關鍵的問題是否用到索引。

11、沒有必要時不要用DISTINCT和ORDER BY，這些動作可以改在客戶端執行。它們增加了額外的開銷。這同UNION和UNION ALL一樣的道理。

12、使用in時，在IN後面值的列表中，將出現最頻繁的值放在最前面，出現得最少的放在最後面，這樣可以減少判斷的次數

13、當用SELECT INTO時，它會鎖住系統表(sysobjects，sysindexes等等)，阻塞其他的連接的存取。創建臨時表時用顯示聲明語句，在另一個連接中SELECT * from sysobjects可以看到 SELECT INTO 會鎖住系統表， Create table 也會鎖系統表(不管是臨時表還是系統表)。所以千萬不要在事物內使用它！！！這樣的話如果是經常要用的臨時表請使用實表，或者臨時表變量。

14、一般在GROUP BY和HAVING字句之前就能剔除多餘的行，所以儘量不要用它們來做剔除行的工作。他們的執行順序應該如下最優：select 的Where字句選擇所有合適的行，Group By用來分組個統計行，Having字句用來剔除多餘的分組。這樣Group By和Having的開銷小，查詢快.對於大的數據行進行分組和Having十分消耗資源。如果Group BY的目的不包括計算，只是分組，那麼用Distinct更快

15、一次更新多條記錄比分多次更新每次一條快,就是說批處理好

16、慎用臨時表，臨時表存儲於tempdb庫中，操作臨時表時，會引起跨庫操作。儘量用結果集和表變量來代替它。

17、儘量將數據的處理工作放在服務器上，減少網絡的開銷，如使用存儲過程。存儲過程是編譯好、優化過，並且被組織到一個執行規劃裏、且存儲在數據庫中的 SQL語句，是控制流語言的集合，速度當然快。

18、不要在一段SQL或者存儲過程中多次使用相同的函數或相同的查詢語句，這樣比較浪費資源,建議將結果放在變量裏再調用。這樣更快。

19、按照一定的次序來訪問你的表。如果你先鎖住表A，再鎖住表B，那麼在所有的存儲過程中都要按照這個順序來鎖定它們。如果你（不經意的）某個存儲過程中先鎖定表B，再鎖定表A，這可能就會導致一個死鎖。如果鎖定順序沒有被預先詳細的設計好，死鎖很難被發現