最近接到客戶提報的問題：無線上傳的數據，服務器處理速度太慢了，300條數據處理了10分鐘。
太誇張了！分析原因發現同事在導入這個系統時是按照原來項目數據庫生成的腳本，可是沒有發現這些腳本都沒有索引。
發現這個問題後，我大悅。立馬按照原來的索引生成後給了客戶，客戶反映提高很多！
可是用了沒多長時間，同一個客戶又提出慢，百般尋求答案，無解。
後來我把數據庫索引全部刪掉，按照給客戶的索引重新建立，發現沒有聚集索引，我再看腳本，聚集索引在非聚集索引後面就變成非聚集了。
汗！後來調整後300條記錄，需要5s，儘管履歷已經存在100多萬，在插入時要用到3個100萬的數據檢索（3個表），現在這個速度已經可以了。
一、主鍵與聚集索引並不是一對一匹配的
一般情況下我們都認爲,聚集索引和主鍵是相互匹配的,因爲只要你在SQLServer表中定義了一個主鍵,那麼SQLServer會爲這個主鍵自動添加聚集索引.但是,如果你先在表中基於任意一列建立聚集索引,然後再選擇另一列作爲主鍵,這時,這個SQLServer將會基於這個主鍵建立一個唯一非聚集索引.
二、聚集索引會被應用到每個查詢中
一個SQLServer表內,最多只能有一個聚集索引,並且表中數據行存儲的位置由聚集索引來決定.表中非聚集索引與數據行的映射,是通過聚集索引來定位的.當聚集索引執行插入操作時,數據表中的行要進行移動,同時該表中所有非聚集索引要重新排列,這是非常消耗資源並且影響SQLServer響應速度的.
所以SQLServer表中的聚集索引一定要避免新添加數據時執行插入操作,保證表中新添加的數據是從索引的尾部追加的.這樣做可以保證聚集索引相對靜態,對非聚集索引的影響也會減小.
創建聚集索引時,要選擇那些數據會不斷增加的字段,最好的例子就是bbs發帖表中,帖子發佈時間,這個字段中的數據是隨時間增長的,理論上講是不會重複的,最適合建立聚集索引.
如果你的聚集索引真的做到了不斷增加,那麼它的填充因子就應該是100%,這個數值越高,每個8KB大小的索引頁記錄的行數就越多,進行相同的掃描時IO、內存和CPU資源就用的越少,換句話說就是查詢效率更高.
三、聚集索引的數據類型位寬將影響查詢效率
聚集索引列的數據類型位寬越小,查詢效率越高,並且由於非聚集索引是依靠聚集索引來影射SQLServer表中數據行的,聚集索引的位寬必將影響表中所有非聚集索引的大小.通常適合作爲聚集索引的類型包括:
Smallint, int, bigint, datetime 和 UNIQUEIDENTIFIER.