下午，所有的SQL慢如牛。

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

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

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

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

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

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

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

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

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

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

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

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

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

所以，我做了些小調(diào)整：

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

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

短暫的小插曲，每天都有。及時(shí)復(fù)盤，提高自己水平。

總結(jié)下，今天用到的技能：

1 - "三板斧"找端倪

2 - 三星索引好幫手

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