數(shù)據(jù)庫索引：

1、復(fù)合索引（where A And B）如果沒有對A和B做單一索引，查詢的時間為a；如果對A做單一索引，查詢時間為b；如果對B做單一索引，查詢時間為c；如果對A、B做復(fù)合索引，查詢的時間為d，那時間的比較就應(yīng)該是a>b=c>d；（比如spMsgReader_Distribute中使用WHERE InfoID=@infoID AND UserID=@userID，插入7000次的時候就很明顯地看到性能了；（8秒比1：50秒）注意升序和降序的區(qū)別？

2、當(dāng)高選擇性的非聚集索引達到5%的選擇性時，該索引是非常有用的；

 3、關(guān)于復(fù)合索引的屬性列位置問題，應(yīng)該把高選擇性的列放到最左邊（已前就忽略了這個高選擇性的位置），那個通過IP和UrlID的SARG中我們可以創(chuàng)建一個IP和UrlID的復(fù)合索引，通過業(yè)務(wù)來說，我們測試的時候可能是IP的重復(fù)量比較大，但是在生成環(huán)境中，應(yīng)該是UrlID的重復(fù)量會比較大，所以就IP放到復(fù)合索引的最左邊；

 4、對EasyURL跳轉(zhuǎn)功能中，需要通過輸入地址來查詢目標地址，這個數(shù)據(jù)庫查詢可以使用覆蓋索引，查詢的速度是最快的；

 5、當(dāng)返回一個聚集索引列和一個非聚集索引列，并且是使用非聚集索引屬性列作為SARG，那么這也是一個索引覆蓋查詢，因為在非聚集索引中包括聚集索引，所以直接在B-Tree就返回了數(shù)據(jù)，不用查詢數(shù)據(jù)頁；

6、在查詢Select語句中用Where字句限制返回的行數(shù)和列數(shù),避免表掃描,如果返回不必要的數(shù)據(jù)，浪費了服務(wù)器的I/O資源，加重了網(wǎng)絡(luò)的負擔(dān)降低性能。

 7、對長字符列的索引，我們可以使用哈希索引，也就是CHECKSUM函數(shù)，具體用法可以看幫助文檔；通常情況下我們都沒有對長字符列建立索引的，而且我們的業(yè)務(wù)邏輯中對長字符作為內(nèi)容的搜索也是不常見的，但是如果有需要，可以考慮哈希索引，有些同學(xué)可能會說為什么不用全文索引呢？因為畢竟全文搜索是要花費很多磁盤空間和IO操作的；
 

【編輯推薦】

1. SQL Server全文索引的硬傷
2. 詳解降低數(shù)據(jù)庫連接數(shù)的方法
3. 索引存儲關(guān)系到數(shù)據(jù)庫的運行效率
4. 實時數(shù)據(jù)庫中的二級壓縮技術(shù)