Sql Server之旅——第九站 看公司這些DBA們設計的這些複合索引

　　這一篇再說下索引的最後一個主題，索引覆蓋，固然學習比較好的捷徑是看看那些大師們設計的索引，看從中能提取些什麼養分的東西，下面咱們看

看數據庫中一個核心的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

 

好了，就像園友說的，索引就是拆東牆補西牆，每建一個索引都須要評估它的利弊。