這一篇再說下索引的最後一個主題，索引覆寫，當然學習比較好的捷徑是看看那些大師們設計的索引，看從中能提取些什麼營養的東西，下面我們看
看資料庫中一個核心的orders表。
一：檢視表的架構
<1> 先檢視這個表的大概架構資訊
從這個訂單表來看大概有89個字段。。。還是蠻多的，可能有太多的曆史原因吧，下面就有一個疑問來了，針對這麼多的字段加上五花八門的類型，如何規劃
好單列索引和複合索引。。。下面我們來看看這些專家們怎麼設計的。
<2> 複合索引
首先聲明一下，由于我的權限有限，不能進行dbcc ind，page等指令，是以我沒有能力判斷下面的索引是include索引還是複合索引，是以這裡統一叫成
複合索引吧。
從上面可以看到，有9個非聚集索引，1個聚集索引，然後可以通過 show_statistics 抽查幾個索引看看到底關聯了哪些字段，找到其中的二個索引，
覆寫多達6列，如索引"idx_order_status_2","ix_o_ordersuid"。
從這兩個索引中關聯的字段大概可以看出兩點資訊：
①：這些字段都比較小，為char(1)，smallint，bit這樣的，自然表示的狀态會比較少。
②：将表中多個狀态少的字段挑選幾個按照通路頻率組合在一起做一個索引。
但是仔細想想，雖然原則上說狀态少的字段不合适建索引，但是類似“訂單狀态(orderstatus”這種字段，肯定是一個被頻繁查詢的列。。。既然是頻繁的列，
肯定就要想辦法優化，方法就是建複合索引，這樣在複雜的sql中更加容易被撞上索引覆寫。
比如下面這樣：
然後繼續挑選幾個索引瞄一瞄。。。一般來說，覆寫1到2個列的索引都叫小索引。
通過上面的索引大概可以看到，eid和finishdate這兩列，一眼掃過就知道應該是一個唯一性比較高的列了，至于為什麼要覆寫2列，那這個就是根據業務
和生産的滾動資料來決定了，那這樣的索引有什麼好處呢？同樣更容易會撞到索引連結，也就是多條件中會走到多個索引，每個索引中貢獻一些列剛好可以
滿足select中的所有列。。。比如下面這樣。
好了，就像園友說的，索引就是拆東牆補西牆，每建一個索引都需要評估它的利弊。