復合索引（where A And B）如果沒有對A和B做單一索引，查詢的時間為a；如果對A做單一索引，查詢時間為b；如果對B做單一索引，查詢時間為c；如果對A、B做復合索引，查詢的時間為d，那時間的比較就應該是a>b=c>d；（比如spMsgReader_Distribute中使用WHERE InfoID=@infoID AND UserID=@userID，插入7000次的時候就很明顯地看到性能了；（8秒比1：50秒）注意升序和降序的區別？
當高選擇性的非聚集索引達到5%的選擇性時，該索引是非常有用的；
關於復合索引的屬性列位置問題，應該把高選擇性的列放到最左邊（已前就忽略了這個高選擇性的位置），那個通過IP和UrlID的SARG中我們可以創建一個 IP和UrlID的復合索引，通過業務來說，我們測試的時候可能是IP的重復量比較大，但是在生成環境中，應該是UrlID的重復量會比較大，所以就IP 放到復合索引的最左邊；
對EasyURL跳轉功能中，需要通過輸入地址來查詢目標地址，這個數據庫查詢可以使用覆蓋索引，查詢的速度是最快的；
當返回一個聚集索引列和一個非聚集索引列，並且是使用非聚集索引屬性列作為SARG，那麼這也是一個索引覆蓋查詢，因為在非聚集索引中包括聚集索引，所以直接在B-Tree就返回了數據，不用查詢數據頁；
在查詢Select語句中用Where字句限制返回的行數和列數,避免表掃描,如果返回不必要的數據，浪費了服務器的I/O資源，加重了網絡的負擔降低性能。
對長字符列的索引，我們可以使用哈希索引，也就是CHECKSUM函數，具體用法可以看幫助文檔；通常情況下我們都沒有對長字符列建立索引的，而且我們的業務邏輯中對長字符作為內容的搜索也是不常見的，但是如果有需要，可以考慮哈希索引，有些同學可能會說為什麼不用全文索引呢？因為畢竟全文搜索是要花費很多磁盤空間和IO操作的；
