下午，所有的SQL慢如牛。

平日里2-3秒搞定的SQL，這會非得弄個7-8秒。timeout更是頻頻爆出。搞得辦公室怨叫聲此起彼伏，真有點《生命協(xié)奏曲》的味道。

我是最聽不得這些哀怨的，不僅僅是喊的難聽，那些消極的聲音，仿佛來自地獄的催命；更多是覺得，那是對我們這些DB Guy及其不友好的宣戰(zhàn)啊。

DBA是公司最寶貴的資源，我們肯定調度過不來。索性自己上吧。還記得之前我說過的調優(yōu)排錯“三板斧”嗎，今天又派上用場了。

第一板斧，找到誰在數(shù)據庫上亂來。

幸好只是開發(fā)庫，只有數(shù)量不多的連接，一查就知道，某個SQL發(fā)出了SOS的等待，占用大量的CPU，而且還在拼命的發(fā)出多線程請求。截獲了它的SQL文本，拿出來一看，差點嚇尿。

如此混亂的編碼，換在平時，我可能都沒興趣看。poorman's formatter 這么好用的插件，估計這朋友對此一無所知。

好嘛，我?guī)湍愀袷交拢?/p>

這回清晰多了。但各種缺陷也暴露無遺。很明顯，會很慢。

丟到 SSMS 里面，足足等了69秒才出來數(shù)據。當時我的汗啊，這么慢的SQL在我的機器上發(fā)出，要被抓出來，不被大家給笑死。L 倒還是那個 L, 不過是 Laugh 罷了。（老讀者一定知道 L 這個梗）

第二板斧，查看執(zhí)行計劃

排除那些復雜的 Index Spool，Stream Aggregation，這里面最吸引我的是同一張表，居然要掃描兩次，就是那張 XXX_PER表。所以我不得不重新看下這段SQL的邏輯，簡直是鬼才！

這種寫法，大約就是“只有我看得懂的SQL，你們離不開我”的想法作祟下，搞出來的鬼。據我經驗分析，往往都是剛出道的小聰明。

但凡看到我之前寫過的文章 如何寫好 5000 行的 SQL 代碼，是絕對不可能寫出這樣的SQL。要么沒懂重構的意義，要么就是甩小聰明。

所以，我做了些小調整：

把所有用到的列，都加到一個索引里面。再檢查下執(zhí)行計劃

干凈了，變快了。4秒，87426 條數(shù)據。18 倍的性能提升。當然，還有提升空間。

短暫的小插曲，每天都有。及時復盤，提高自己水平。

總結下，今天用到的技能：

1 - "三板斧"找端倪

2 - 三星索引好幫手

3 - 執(zhí)行算子要常翻