這一篇再說下索引的最后一個主題，索引覆蓋，當然學習比較好的捷徑是看看那些大師們設計的索引，看從中能提取些什么營養的東西，下面我們看
看數據庫中一個核心的Orders表。
一：查看表的架構
<1> 先查看這個表的大概架構信息
1 --查看表的架構信息 2 SELECT c.column_id,c.name,t.name FROM sys.columns AS c 3 JOIN sys.types t 4 ON c.system_type_id=t.system_type_id 5 WHERE c.object_id=object_id('O_Orders') 6 ORDER BY c.column_id
從這個訂單表來看大概有89個字段。。。還是蠻多的，可能有太多的歷史原因吧，下面就有一個疑問來了，針對這么多的字段加上五花八門的類型，如何規劃
好單列索引和復合索引。。。下面我們來看看這些專家們怎么設計的。
<2> 復合索引
首先聲明一下，由于我的權限有限，不能進行DBCC IND，PAGE等命令，所以我沒有能力判斷下面的索引是include索引還是復合索引，所以這里統一叫成
復合索引吧。
1 SELECT name,type_desc FROM sys.indexes WHERE object_id=object_id('O_Orders')
從上面可以看到，有9個非聚集索引，1個聚集索引，然后可以通過 SHOW_STATISTICS 抽查幾個索引看看到底關聯了哪些字段，找到其中的二個索引，
覆蓋多達6列，如索引"idx_order_status_2","IX_O_OrdersUID"。
DBCC SHOW_STATISTICS(O_Orders,idx_order_status_2) DBCC SHOW_STATISTICS(O_Orders,IX_O_OrdersUID)
從這兩個索引中關聯的字段大概可以看出兩點信息：
①：這些字段都比較小，為char(1)，smallint，bit這樣的，自然表示的狀態會比較少。
②：將表中多個狀態少的字段挑選幾個按照訪問頻率組合在一起做一個索引。
但是仔細想想，雖然原則上說狀態少的字段不合適建索引，但是類似“訂單狀態(OrderStatus”這種字段，肯定是一個被頻繁查詢的列。。。既然是頻繁的列，
肯定就要想辦法優化，方法就是建復合索引，這樣在復雜的sql中更加容易被撞上索引覆蓋。
比如下面這樣：
1 SET STATISTICS IO ON 2 SELECT OrderStatus, ProcessStatus, SendTicketCity, FlightAgency, Eticket, OrderID 3 FROM dbo.Orders WHERE OrderStatus='P' AND ProcessStatus='1' AND SendTicketCity=1
然后繼續挑選幾個索引瞄一瞄。。。一般來說，覆蓋1到2個列的索引都叫小索引。
1 DBCC SHOW_STATISTICS(O_Orders,idx_eid_orderdate) 2 DBCC SHOW_STATISTICS(O_Orders,IX_O_Order_FinishDate)
通過上面的索引大概可以看到，Eid和FinishDate這兩列，一眼掃過就知道應該是一個唯一性比較高的列了，至于為什么要覆蓋2列，那這個就是根據業務
和生產的滾動數據來決定了，那這樣的索引有什么好處呢？同樣更容易會撞到索引鏈接，也就是多條件中會走到多個索引，每個索引中貢獻一些列剛好可以
滿足select中的所有列。。。比如下面這樣。
1 -- 可以看到，select中的所有列都是有idx_eid_orderdate 和 IX_O_Order_FinishDate 貢獻 2 SELECT OrderID,FinishDate,PrepayType,Eid,OrderDate 3 FROM dbo.O_Orders WHERE Eid='cctv1' AND FinishDate>2015-1-1
好了，就像園友說的，索引就是拆東墻補西墻，每建一個索引都需要評估它的利弊。