SQL 陳述式最佳化總結

個人日常最佳化SQL語句的總結筆記

目前 DB 承受 日平均 500W PV 左右的網站，資料檔案大小在20G左右，表資料量 在 50 - 500 W 左右

僅供參考：

1  . 查詢的資料行分布情況，決定索引是否用得上，如果查詢的資料行在資料表中分布均勻，且所佔比重較大，能用上索引；反之，用不上索引

2  . select 的欄位數目，特別是 長度較大的欄位，對 語句的執行時間影響較大

3  . 語句中有 distinct 時，再在 where 語句中限制日期範圍的話，反而會影響效能，無 distinct 時，執行情況是一樣的

4  . distinct 一般佔到總語句開銷的 65 %左右

5  . newid 則視結果集而定，結果集越大，newid 所佔語句的總開銷比例也就越大

6  . group by 歸總時，語句開銷和Top 無關，所以，盡量少在大表中group by。

7  . group by 的欄位越多，開銷越大，且這些欄位是用不上索引的，但是 where 中的條件是可以用上索引的。但是不可估量的是，用上索引也不一定能減少開銷

8  . 非叢集索引，在 order by 中是用不上的

9  . Row_Number 在IO操作上不是十分的出色，但是在佔用CPU資源上，卻做的非常好。總體上，還是相當不錯的，執行時間較短。

10. 在部分情況下，如果 Or 用好，是和 In 的效率一樣的

11. 查詢條件過多也會影響效能，且較嚴重

12. 查詢中，UserName='ssssss' 的效能往往會比 UserID=123456 的效能要好

13 . 當語句中出現 in(select id from table1) 時，in裡面的運算式一定要加top ，比如 select top 10 * from tables where id in(select top 100 id from table2)，特別是在 in 裡面取出來的資料比較多，外表又很大的情況

14 . 叢集索引一定要建在在表中分布均勻的欄位、增減規律的欄位上，比如日期，而盡量避免將叢集索引建立在UserID等欄位上

15 . 當 where 中有 like 條件匹配時，where 中的非叢集索引就會失效，引起全表掃描，但是叢集索引是可以用到的

16.  如過允許，請將 可能 引起全表掃表的 SQL 陳述式，加上 未提交讀 的事物隔離等級設定,即 no lock

不斷補充中 ......