我們將利用advanturewords2008r2中的sales.salesorderdetail表，其中有12萬條資料，非常適合用於測試。不過我們不直接在這張表上做測試，因為這張表上已經有索引了。我們需要新建一張表，將該表中的資料匯入我們新建的test和test2表。test和test2的建立方法有兩種，我們選擇第二種。
下面我們將通過實驗來說明聚集索引和非聚集索引在查詢效率上的影響。根據logic read以及execution plan我們能夠更加清晰知道索引的結構，以及sql server是如何查詢資料的。
資料庫中經常會存在復合索引，那麼復合索引在什麼情況下會起到查詢優化作用，又在什麼情況下起不到作用呢。如果查詢條件是復合索引的非leading column，那麼索引不起作用，不會使用這個復合索引。
今天看到了中的資料庫查詢效能優化之利器—索引（二），看著覺得有點不對勁，所以對文中的疑點進行測試。
參考：首先我們準備實驗資料，在這裡我新建一張orderdetail2，並將adventureworks2008r2的 adventureworks2008r2.sales.salesorderdetail表中的其中四列匯入orderdetail2表中，tsql如下所示：
然後我們按照unitprice來查詢，查詢語句如下：
select其查詢計畫如下：*from orderdetail2 where unitprice =
5.70
從上述查詢計畫我們可以看出，乙個查詢使用了兩個索引。在idx_nc_unitprice上面是哦那個了index seek，而在pk_salesorderdetailid上面使用了clustered index seek。
接下來我們建立乙個復合索引包含salesorderid,carriertrackingnumber,unitprice這三個列，然後測試復合索引在什麼情況下會被使用。建立復合索引的tsql如下所示：
（1）然後我們將查詢條件設定為復合索引的引導列，我們會發現：where條件是引導列，不論查詢的是所有列或者是單列salesorderid，都使用了復合索引，而沒有使用單列索引。tsql查詢如下所示：
查詢計畫如下圖所示：
（2）如果查詢條件是非引導列，那麼將使用單列索引，而不使用復合索引，tsql查詢如下所示，執行計畫在疑問一中已經給出。
（3）where查詢條件包含了引導列，那麼不論引導列在where條件的何處(多條件情況)，都會使用復合索引。
查詢計畫如（1）所示。
（4）不包含引導列。假如where條件不包含引導列，那麼將不會使用復合索引。比如執行如下tsql查詢，就沒有使用復合索引，而是使用了兩個單列各自的非聚集索引。這又是乙個「乙個查詢可以使用多個索引」的例子。
select上述查詢的查詢計畫如下圖所示：*from orderdetail2 where carriertrackingnumber=
'48f0-4f3e-ae
'and unitprice=
1.374
總結：對於符合復合mutilindex(name,age,tel)。若判別條件為(name),(name,age),(name,tel),(name,age,tel)都可以使用該復合索引，而(age,tel),(tel)都不能夠使用該做引。
索引字段順序對效率的影響
個人總結幾點 1 驅動表中的索引要將區間字段 sendtime之類 放到固定值 orgid等 的後面 2 驅動表的連線字段可以放在索引最後，以避免讀取rowid 3 連線表的連線欄位要放在索引最前面。舉個例子 select count as col 0 0 from rec bankinstruct...
mysql 查詢冗餘索引 冗餘索引對查詢效率的影響
結果一 與執行計畫相關的索引 出現在possible keys的那些 索引的數量與sql執行消耗時間成正比。create index idx1 on test index performance col1 create index idx2 on test index performance col...
資料庫主鍵設定對查詢效率的影響
在資料庫表設計時，許多人為採用int型別還是guid uniqueidentifyer 作為主鍵爭論不休，有認為int型字段好的，有認為guid好的，很多時候的焦點集中在效率上。為了弄清事實真相，我想還是要以實驗來進行測試為準。以下就是為了測試插入效率而寫的一段指令碼。測試環境是 xeon 1.6 ...