今天調優某電信的大型資料庫，是乙個日誌型的表，其中有個自增列欄位和時間（時間是每個小時小時來的，每個小時有大概23萬條記錄），以及點選次數等日誌資訊，資料量在4000萬以上，sp_spaceused使用了大概2g多的磁碟空間。整個表沒有分割槽。整個表都是插入查詢，沒有更新操作。
有乙個基於時間欄位上的時間段where範圍選擇，然後聚合找到某些型別的聚合值。
觀察發現自增列字段就是乙個擺設，沒有任何作用，也不做任何表的外來鍵，只是可能當時開發人員在設計表的時候就不管3721都來乙個自增列主鍵，導致在對date欄位上的非聚集索引掃瞄後，還需要去聚集索引樹上seek一下，這下子就增加乙個巢狀查詢了。去掉表上的主鍵聚集索引，將表回歸為堆，這樣在非聚集索引掃瞄後直接就拿到rid找相應行了。
後來又想辦法整了個date欄位上的include索引，將要彙總的字段都加到非聚集索引上來，連rid查詢都不要了。include雖然增加磁碟開銷，但是速度上去很多，且沒有針對索引的更新，不涉及索引拆分等費時操作，所以覺得還是值得。
最後優化結果，由45秒到20秒。
優化結果還比較滿意，最後最重要的是因為io始終將不下來，因為資料太多了。
不知道還有沒有辦法能想想的。
其實以前自己在設計資料庫的時候也經常對錶開始就來乙個主鍵，而並沒有考慮其實際意義，導致表的操作非常困難。
這個日誌型別的表基本不需要自增主鍵字段，他不會根據某一日誌ｉｄ範圍來查詢或者更新日誌。
但在優化的時候有個問題覺得很奇怪：
４０００萬的資料，查詢其中的２萬條，根據日期上的過濾，我想應該是乙個巢狀的書籤查詢計畫，結果看到ｍｓｓｑｌ給出的答案卻是聚集索引掃瞄。４０００萬比２萬的資料，卻寧願表掃瞄而不願意做巢狀？只有指定了使用非聚集索引後查詢計畫才改成巢狀的書籤查詢。
問問大家這個是為何呢？難道聚集索引掃瞄的ｉｏ更低？
一次Java垃圾收集調優實戰
cms收集器 暫停時間優先 配置引數 xx useconcmarksweepgc 已預設無需配置的引數 xx useparnewgc parallel收集新生代 xx cmspermgensweepingenabled cms收集持久代 xx usecmscompactatfullcollectio...
一次效能調優的實戰
專案情況 是乙個大型公司的內部辦公系統，該系統有兩個和一般企業應用不太一樣的特點 一是使用者量非常多，人員數達到2w左右，另乙個是採用分級管理的形式，各個分公司資料分開管理。我們的定位 我們是作為業務平台的提供商參與這個專案的，我們提供底層的開發平台，系統整合商在此基礎上進行二次開發。在專案從開發到...
一次Java垃圾收集調優實戰
cms收集器 暫停時間優先 配置引數 xx useconcmarksweepgc 已預設無需配置的引數 xx useparnewgc parallel收集新生代 xx cmspermgensweepingenabled cms收集持久代 xx usecmscompactatfullcollectio...