SQL Server調優實戰 亂建聚集索引的後果

今天調優某電信的大型資料庫，是一個日誌型的表，其中有個自增列欄位和時間(時間是每個小時小時來的，每個小時有大概23萬條記錄)，以及點選次數等日誌資訊，資料量在4000萬以上，sp_spaceused使用了大概2G多的磁碟空間。整個表沒有分割槽。整個表都是插入查詢，沒有更新操作。

　　有一個基於時間欄位上的時間段where範圍選擇，然後聚合找到某些型別的聚合值。

　　觀察發現自增列欄位就是一個擺設，沒有任何作用，也不做任何表的外來鍵，只是可能當時開發人員在設計表的時候就不管3721都來一個自增列主鍵，導致在對date欄位上的非聚集索引掃描後，還需要去聚集索引樹上seek一下，這下子就增加一個巢狀查詢了。去掉表上的主鍵聚集索引，將表迴歸為堆，這樣在非聚集索引掃描後直接就拿到RID找相應行了。

　　後來又想辦法整了個date欄位上的include索引，將要彙總的欄位都加到非聚集索引上來，連RID查詢都不要了。include雖然增加磁碟開銷，但是速度上去很多，且沒有針對索引的更新，不涉及索引拆分等費時操作，所以覺得還是值得。

　　最後優化結果，由45秒到20秒。

　　優化結果還比較滿意，最後最重要的是因為IO始終將不下來，因為資料太多了。

　　不知道還有沒有辦法能想想的。

　　其實以前自己在設計資料庫的時候也經常對錶開始就來一個主鍵，而並沒有考慮其實際意義，導致表的操作非常困難。

　　這個日誌型別的表基本不需要自增主鍵欄位，他不會根據某一日誌ID範圍來查詢或者更新日誌。

　　但在優化的時候有個問題覺得很奇怪：

　　4000萬的資料，查詢其中的2萬條，根據日期上的過濾，我想應該是一個巢狀的書籤查詢計劃，結果看到MSSQL給出的答案卻是聚集索引掃描。4000萬比2萬的資料，卻寧願表掃描而不願意做巢狀?只有指定了使用非聚集索引後查詢計劃才改成巢狀的書籤查詢。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/16436858/viewspace-591030/，如需轉載，請註明出處，否則將追究法律責任。