最近在MSDN回答一個問題:
建立非叢集索引時,索引鍵資料行、包含資料行的順序是否影響查詢效能?
回答問題時
發現自己對索引概念都是以經驗角度出發,怕自己有錯誤的邏輯地方
覺得滿有趣的
提出跟大大們來做討論、研究。
以下個人經驗跟觀點:
1.先建立一個測試DDL:
CREATE TABLE TestTable([col1] varchar(2), [col2] varchar(2), [col3] varchar(2));
Create Nonclustered Index Index_TestTable on TestTable ([col1], [col2]) ;
2.Index Scan也是索引功效,而且效能大部分情況會輸給 Index Seek,少部分不會
。
(通常在表資料量小的時候)
而要使用Index Seek還是Index Scan是靠DBMS的運算邏輯決定的。
scan跟seek差別概念可以看S.O這篇文章
來源:Index Seek vs Index Scan in SQL Server - Stack Overflow
3.資料量小的時候系統有時候會判斷"全表格搜尋"為最佳,而不走索引
舉例:
當資料量小的時候(測試資料5000筆數)就算條件都在索引設定內,還是會走table scan
select [col1], [col2], [col3] from TestTable
where [col1] = '' and [col2] = '' ;
但有時候會判定走Index Seek
,當資料量達到一定程度(測試資料100000筆數)
select [col1],[col2] from TestTable3
where [col1] = '' and [col2] = ''
當資料量小的時候又會走Index Scan
(測試資料500筆數),select欄位都在索引欄裡面
P.S
中英對照:
英 | 中 |
---|---|
Index Scan | 索引掃描 |
Index Seek | 索引搜尋 |
因為col3沒有在索引內,所以就算條件都在索引設定內,還是會走全表格搜尋
那麼使用強制指定索引
會改善嗎?
JOIN POItem AS iA WITH(INDEX(索引)) ON bA.odno=iA.odno
發現我的描述有錯誤
我更新第三點了
可以強制指定索引
但效能似乎不會比較好,
在小資料時候資料庫會判定不走索引