其實當DBA最有成就感的時候, 就是效能調校的成功, 讓查詢的速度有縮短更快

這次的case就是有個存放binary的影像Table, 使用者在調閱影像檔案時, 花費大約52sec的時間

後來AP(應用程式人員)有提供給我執行的Store Procedure, 看看是否可以有調整的地方

我花了些時間研究, 發現瓶頸點就在那個存放影像的Table, 雖然之前已經有建立兩組非叢集(Non clustered)索引, 沒有primary key, 但是在Table join的語法中, 似乎沒有使用到, 還是會做full table scan, 資料表大約有兩百萬筆的資料, 因此速度當然會很慢

處理的方式:
我先試著建立一個clustered 的索引, 因為實體的檔案順序會因為clustered index的順序而排列, 而non clustered不會, 建完後測試, 有縮短到12秒, AP覺得可以接受, 不過我還是覺得還可以改進, 嘗試把clustered index drop掉, 重新建一個PK(重建PK同時,SQL會自動建立clustered index), 想不到建完後重跑該Store Procedure, 居然不到一秒就顯示結果了, 讓我感覺到非常爽, 終於有點成就感

隔天AP請使用者再測試時, 整個過程花費約12秒, 整整縮短了40秒, 當然是不可能縮短到一眨眼的時間, 畢竟還要加上網路傳輸, AP程式的處理及展現, 不過可以在SQL減少查詢的時間不到一秒, 真的讓我有當DBA的感覺了, 金送~~

這次的經驗說明了, 其實PK+clustered key比單純的clustered key效果還好, 真的要有建PK的好習慣

Paul 發表在 痞客邦 PIXNET 留言(0) 人氣()