一、背景

慢查詢?cè)?MySQL 數(shù)據(jù)庫(kù)管理中，已經(jīng)是再熟悉不過(guò)的事情了，只要我們?cè)谑褂?MySQL，那慢查詢就會(huì)一直存在下去，因?yàn)椴还苁菢I(yè)務(wù) APP，還是 MySQL，他們的狀態(tài)都是動(dòng)態(tài)變化的，在這個(gè)動(dòng)態(tài)的服務(wù)中，可能經(jīng)常遇到的問(wèn)題是，某幾個(gè)指標(biāo)的變化形成了共振效應(yīng)，進(jìn)而導(dǎo)致本來(lái)不慢的查詢語(yǔ)句變成慢查詢，本來(lái)可以走二級(jí)索引并很快返回的語(yǔ)句變成了全表掃描，這還不止，可能這種影響范圍會(huì)繼續(xù)進(jìn)一步擴(kuò)大，導(dǎo)致整個(gè)實(shí)例或者集群被打死，出現(xiàn)一些“被影響”的很慢的查詢語(yǔ)句，從而產(chǎn)生了我們通常意義上的“雪崩效應(yīng)”，最終導(dǎo)致的是由慢查詢引起的數(shù)據(jù)庫(kù)故障。

但這樣的故障，真是由慢查詢導(dǎo)致的么？這個(gè)我認(rèn)為不一定，具體原因很難窮盡，但在一個(gè)動(dòng)態(tài)變化的環(huán)境中，多個(gè)因素導(dǎo)致了共振效應(yīng)，進(jìn)一步導(dǎo)致雪崩現(xiàn)象，這應(yīng)該是確定的。面對(duì)這樣的問(wèn)題，我們應(yīng)該怎么解決，或者提前避免呢？可能很多人會(huì)認(rèn)為因?yàn)槭枪舱駥?dǎo)致的，是不是要去查到具體共振因素，這樣問(wèn)題就解決了？我想說(shuō)的是，這種解決辦法有時(shí)候可以解決問(wèn)題，但通常問(wèn)題發(fā)生之后，共振的場(chǎng)景已經(jīng)不見(jiàn)了，我們此時(shí)見(jiàn)到的只有慢查詢，除非有很全面的日志，不然這種方法不具有可操作性。

二、解決辦法

對(duì)于上面出現(xiàn)的問(wèn)題，我們不能從原因上解決慢查詢，那么是不是可以考慮從結(jié)果上去解決呢？結(jié)果就是慢查詢，也就是說(shuō)，我們是不是只需要把慢查詢消滅了，就可以把相應(yīng)的雪崩避免了？

答案是肯定的，我們可以想想，如果雪崩出現(xiàn)的時(shí)候，也就是雪崩引起的故障出現(xiàn)的時(shí)候，我們是咋處理故障的？一般情況下，也是通過(guò)不斷殺慢查詢的方式來(lái)解決問(wèn)題的，讓擁堵消失，擁堵消失之后，數(shù)據(jù)庫(kù)本身的狀態(tài)就平靜了，業(yè)務(wù)就可以繼續(xù)有條不紊的訪問(wèn)了，所以用同樣的原理，我們?nèi)绻茉诠舱癯霈F(xiàn)之后，第一批慢查詢出現(xiàn)的時(shí)候，將其殺掉，這樣可能就能有效避免后續(xù)的雪崩效應(yīng)，這樣的推論是沒(méi)有問(wèn)題的。

三、殺慢查詢的方式

很多人想到了上面的解決方案，就是將慢查詢殺掉，但在慢查詢一開(kāi)始出現(xiàn)的時(shí)候，壓力還不大，數(shù)據(jù)庫(kù)可能可以扛過(guò)去，DBA 可能并不會(huì)注意到這個(gè)數(shù)據(jù)庫(kù)“將來(lái)”會(huì)出現(xiàn)問(wèn)題，所以并不會(huì)選擇殺掉，只有惡化了，或者已經(jīng)出現(xiàn)小面積的雪崩了，才會(huì)選擇去殺掉慢查詢，但此時(shí)殺掉的邏輯很簡(jiǎn)單——只要是查詢的，時(shí)間大于多少的，可能就會(huì)被殺掉了，大不了再多加幾個(gè)過(guò)濾條件而已，比如狀態(tài)是 statistics，方式是大同小異的，但這樣的方式有很多弊端，我列舉如下：

1. 很難做到常態(tài)化

就像上面說(shuō)的，在雪崩之前，并不能預(yù)測(cè)到當(dāng)前數(shù)據(jù)庫(kù)馬上要故障了。就自動(dòng)啟動(dòng)殺慢查詢這個(gè)動(dòng)作，因?yàn)閿?shù)據(jù)庫(kù)是一個(gè)動(dòng)態(tài)服務(wù)，當(dāng)前的服務(wù)水平，和服務(wù)能力，需要綜合各種指標(biāo)來(lái)判斷，包括 CPU、內(nèi)存、多實(shí)例互相影響、IO、并發(fā)個(gè)數(shù)、Buffer Pool的有效性等等，即使是人工去判斷，也很難做到，所以常態(tài)化程序去決定要不要?dú)⒁粋€(gè)慢查詢，基本是無(wú)稽之談。這種殺慢查詢的方法，只能用來(lái)在處理故障的時(shí)候使用，而不是常態(tài)化。

2. 很難做到準(zhǔn)確

這種殺慢查詢的方法，其實(shí)就是憑借經(jīng)驗(yàn)值，綜合各種指標(biāo)，去制定殺慢查詢的策略，比如當(dāng)機(jī)器 Load，或者 CPU 使用率到達(dá)多少的時(shí)候，就開(kāi)始?xì)⒘耍?qǐng)問(wèn)，在多實(shí)例模式下，你如何判斷是 3306 導(dǎo)致的 Load 升高，而不是 3307 呢？比如再考慮 IO 的問(wèn)題，如果發(fā)現(xiàn)某一個(gè)時(shí)間 IO 特別高，然后就開(kāi)始啟動(dòng)殺慢查詢的操作，IO 高了你如何去判斷是哪個(gè) SQL 語(yǔ)句導(dǎo)致的 IO 高？判斷不出來(lái)的話，難道是要全部殺掉嗎？IO達(dá)到多少的時(shí)候要?dú)ⅲ?0？50？還是 100？這個(gè)由誰(shuí)來(lái)定義，假定定義為 30，那 29 要不要?dú)⒛?？如何確定30是有問(wèn)題的，而 29 是沒(méi)有問(wèn)題的？同時(shí)業(yè)務(wù)出故障，還有一個(gè)容忍度，有些業(yè)務(wù) 30 就可能出問(wèn)題了，但有些業(yè)務(wù) load 到達(dá) 100 也沒(méi)問(wèn)題，那請(qǐng)問(wèn)用什么邏輯來(lái)區(qū)分對(duì)待不同的數(shù)據(jù)庫(kù)呢？因?yàn)楹苊黠@的是，不同數(shù)據(jù)庫(kù)使用相同的判斷指標(biāo)，是非常不明智的。其實(shí)這里舉了兩個(gè)指標(biāo)的例子，想說(shuō)明的問(wèn)題是，最終這種方式，可能就是亂殺一通，本身沒(méi)問(wèn)題，卻制造了不少問(wèn)題，本身有問(wèn)題卻并沒(méi)有解決，請(qǐng)問(wèn)，殺出來(lái)問(wèn)題，誰(shuí)來(lái)負(fù)責(zé)？

3. 很難做到自動(dòng)化

自動(dòng)化有一個(gè)程度的問(wèn)題，這里包括兩種，一種是自動(dòng)決定要不要?dú)?，要?dú)⑹裁?，另一種是需要?dú)⒌臅r(shí)候 DBA 啟動(dòng)自動(dòng)化腳本去殺，這里最關(guān)鍵的問(wèn)題是決策問(wèn)題，什么時(shí)候啟動(dòng)的問(wèn)題。很明顯，人判斷比機(jī)器判斷靠譜多了，目前 AIDBA 還不具備這樣的能力，如果不具備，那就沒(méi)辦法談自動(dòng)化了，只能是人工觸發(fā)，很明顯這就是在處理故障的問(wèn)題，而不是提前避免或者預(yù)防故障的問(wèn)題了。

4. 很難做到統(tǒng)一化

就像上面說(shuō)到的，不同業(yè)務(wù)線，不同的機(jī)器性能，不同的 SQL 語(yǔ)句，不同的數(shù)據(jù)量，不同的索引，不同的表大小，一個(gè)語(yǔ)句執(zhí)行多久需要被殺掉？掃描多少行需要被殺掉？Load 達(dá)到多少需要被殺掉？并發(fā)量達(dá)到多少又需要被殺掉呢？相關(guān)指標(biāo)不一而足，但核心問(wèn)題是，這些指標(biāo)難道有一個(gè)標(biāo)準(zhǔn)嗎？達(dá)到這個(gè)標(biāo)準(zhǔn)就肯定出問(wèn)題嗎？這個(gè)誰(shuí)能定這樣的邏輯？誰(shuí)又敢定呢？假如達(dá)到某個(gè)標(biāo)準(zhǔn)就肯定出問(wèn)題，或者誤殺了之后，業(yè)務(wù)自己承擔(dān)責(zé)任，那不同業(yè)務(wù)肯定具有不同的指標(biāo)，那么多數(shù)據(jù)庫(kù)實(shí)例，如何管理這些指標(biāo)呢？這些都是問(wèn)題。

5. DBA 不了解 SQL 語(yǔ)句

DBA 在運(yùn)維過(guò)程中的角色，大多數(shù)是去做 DB 本身的一些運(yùn)維工作，比如遷移、風(fēng)險(xiǎn)控制、故障處理、拆分、優(yōu)化等，但針對(duì) SQL 語(yǔ)句本身，只有業(yè)務(wù)自己了解其內(nèi)部邏輯及語(yǔ)句之間的相關(guān)邏輯等，一個(gè)語(yǔ)句執(zhí)行多少時(shí)間是合理的，超過(guò)多少時(shí)間是不合理的，這種信息 DBA 是不了解的，這方面沒(méi)有任何專業(yè)度可言，而現(xiàn)在恰恰是要把殺 SQL 語(yǔ)句的決策交給 DBA，這是荒唐的，不可信的，DBA 不可以去做這樣的決定，除非數(shù)據(jù)庫(kù)此時(shí)已經(jīng)故障了，這是故障處理的范疇。因?yàn)?DBA 沒(méi)有能力去做這個(gè)事情，那就不做，因?yàn)檫\(yùn)維邏輯很簡(jiǎn)單，DBA 不做沒(méi)有把握的事情。

6. 業(yè)務(wù)沒(méi)辦法做決定

上面也講到了，判斷指標(biāo)包括很多，沒(méi)有標(biāo)準(zhǔn)能確定一個(gè)指標(biāo)達(dá)到了某個(gè)值就肯定出問(wèn)題，或者小于某個(gè)值就肯定沒(méi)問(wèn)題，這個(gè) DBA 沒(méi)辦法去定義，也沒(méi)有經(jīng)驗(yàn)值可用，但這事兒要做的話，DBA 沒(méi)有辦法做到，也沒(méi)有權(quán)利決定是不是殺慢查詢，是不是可以把這些參數(shù)的決定權(quán)交給業(yè)務(wù)開(kāi)發(fā)自己去定義，比如他關(guān)心的某個(gè)數(shù)據(jù)庫(kù)，如果出現(xiàn)慢查詢的話，給出一系列指標(biāo)，這些指標(biāo)達(dá)到多少的時(shí)候就去殺，指標(biāo)之間的關(guān)系是或還是與，或者可以更精細(xì)化的定制，系統(tǒng)做得非常精細(xì)，或和與可以隨便定制，但這樣的問(wèn)題是，業(yè)務(wù)看到 Load 這個(gè)框的時(shí)候，應(yīng)該填多少呢？多少才是沒(méi)有問(wèn)題的，或者給一個(gè)數(shù)據(jù)庫(kù)指標(biāo)，比如并發(fā)量，達(dá)到多少就會(huì)有問(wèn)題呢？這個(gè)時(shí)候我相信，業(yè)務(wù)是懵的，這是跨領(lǐng)域的，你雖然把決定權(quán)交出去了，但他在專業(yè)度上面，沒(méi)辦法做這個(gè)決定，他怎么會(huì)把并發(fā)度與故障聯(lián)系起來(lái)呢？或者 Load 與故障聯(lián)系起來(lái)呢？這更是無(wú)稽之談了。

7. 責(zé)任界定

這種殺慢查詢的方式，上面已經(jīng)講得非常清楚了，沒(méi)有優(yōu)點(diǎn)只有缺點(diǎn)，花了大力氣還惹一身騷，吃力不討好，做了一個(gè)非常強(qiáng)大的系統(tǒng)，最后不知道如何下手，不知道如何去執(zhí)行，那不是白費(fèi)力氣了么？這種方式存在一個(gè)很大的問(wèn)題是，存在大量的錯(cuò)殺問(wèn)題，殺錯(cuò)了，出故障了，誰(shuí)的責(zé)任？這意味著出現(xiàn)的局面是各種扯皮，各種推卸責(zé)任，之后，可能會(huì)進(jìn)入無(wú)休止的調(diào)參運(yùn)動(dòng)中，這樣 DBA /開(kāi)發(fā)就成功地做了一次華麗轉(zhuǎn)身，請(qǐng)叫我們調(diào)參工程師。

8. 數(shù)據(jù)庫(kù)核心是服務(wù)

最后一個(gè)問(wèn)題，其實(shí)是 DB 的核心作用，作為 DBA 或者了解 DBA 的人都知道，操作系統(tǒng)、手機(jī)系統(tǒng)、APP 等系統(tǒng)出了名的運(yùn)維三板斧之一是：重啟，重啟是很湊效的。但數(shù)據(jù)庫(kù)不是這樣，數(shù)據(jù)庫(kù)是管理數(shù)據(jù)的，重啟導(dǎo)致的問(wèn)題可能更大，所以數(shù)據(jù)庫(kù)的運(yùn)維思路是盡可能讓他活著，盡可能讓他好好地活著，這樣的目的只有一個(gè)，就是更好的服務(wù)業(yè)務(wù)，所以不管任何時(shí)候，我們第一思路是提供服務(wù)，而不是寧愿錯(cuò)殺，也要在某種情況下就進(jìn)入拒絕服務(wù)的狀態(tài)，這種思路是有問(wèn)題的，不符合數(shù)據(jù)庫(kù)運(yùn)維思路的。

上面講了殺慢查詢的綜合方法的各種弊端，很明顯這是不靠譜的，不負(fù)責(zé)任的，后患無(wú)窮的，不解決問(wèn)題的，我們時(shí)刻要堅(jiān)決守住這樣的底線，不要去做這樣的事情，不然肯定是徒勞的，吃力不討好的。

那還有沒(méi)有一種辦法，在有效避免上述所有問(wèn)題的同時(shí)，還能解決慢查詢帶來(lái)的各種問(wèn)題呢？答案是有的。

四、解鈴還須系鈴人

我們做這個(gè)事情，需要換一種思路去考慮問(wèn)題，語(yǔ)句是開(kāi)發(fā)寫的，語(yǔ)句是從應(yīng)用程序訪問(wèn)過(guò)來(lái)的，那只有應(yīng)用端或者開(kāi)發(fā)才了解 SQL 語(yǔ)句的情況，包括需要執(zhí)行多久（SQL 語(yǔ)句的超時(shí)時(shí)間設(shè)置），或者說(shuō)執(zhí)行多長(zhǎng)時(shí)間，就肯定是有問(wèn)題的，而語(yǔ)句相關(guān)的其它參數(shù)，他們是不一定能知道的，他們?cè)谥恢肋@樣的信息的情況下，如何去殺慢查詢呢？有三種辦法：

1.注冊(cè)制

DBA 開(kāi)發(fā)一個(gè)“強(qiáng)大”的系統(tǒng)，用來(lái)注冊(cè) SQL 語(yǔ)句，指標(biāo)包括數(shù)據(jù)庫(kù)地址，最大執(zhí)行時(shí)間，其它都可以不要，有了這個(gè)系統(tǒng)，DBA 可以在每一個(gè)數(shù)據(jù)庫(kù)上面搞一個(gè) Agent，不斷地去訪問(wèn)這個(gè)配置庫(kù)，同時(shí)去看 Processlist 中的信息，如果語(yǔ)句和時(shí)間都能匹配得上，就殺掉，這種辦法當(dāng)然比上面的辦法強(qiáng)多了，至少執(zhí)行殺的動(dòng)作是有決策根據(jù)的，這種決策根據(jù)是建立在業(yè)務(wù)對(duì)自己語(yǔ)句的了解以及對(duì)健康度的風(fēng)險(xiǎn)把控之上的，這樣就可以有效的避免意外情況相互擁堵導(dǎo)致的數(shù)據(jù)庫(kù)雪崩問(wèn)題，至少在雪崩之前就可以將這個(gè)擁堵的狀態(tài)解決掉。但這種辦法也是有問(wèn)題的，久而久之這個(gè)配置庫(kù)會(huì)非常大，因?yàn)闃O限條件下，線上出現(xiàn)的每個(gè) SQL 語(yǔ)句都會(huì)出現(xiàn)在這里，這個(gè)殺慢查詢的 Agent 就沒(méi)辦法良好運(yùn)行了，并且匹配的是整個(gè) SQL 語(yǔ)句，涉及到模式處理問(wèn)題，以及很重的字符串比較的問(wèn)題，效率不能保證。所以，這種辦法也是不可行的。

2.簽名制

還有一種更好的辦法，就是在 SQL 語(yǔ)句中加上注釋，類似這樣的形式：

/*!99999 21B2438F55 kill me when query_time > 10 app comments*/ select sleep(10);

下面首先講一下設(shè)計(jì)細(xì)節(jié)：

1）99999 表示的是 MySQL 版本，99999 大于現(xiàn)在所有的 MySQL 版本，所以注釋里面的內(nèi)容就會(huì)被 MySQL 忽略，所以這用的是 MySQL 所支持的方式。

2）后面的 MD5 值，是為了做簽名的，主要是為了防止錯(cuò)殺的，一個(gè) MD5 填在這里，如果能碰巧雷同了，那是不是可以買彩票了。所以這個(gè) MD5 值，可以很好地用來(lái)給 DBA 做語(yǔ)句識(shí)別的功能，而不用去比較整個(gè)字符串了，識(shí)別到這個(gè)值之后，再去解析其它信息，匹配到了，則執(zhí)行殺的動(dòng)作。

3）后面的 "kill me when query_time > 10"，類似是一個(gè)協(xié)議內(nèi)容，明確表示這個(gè)語(yǔ)句要啟用殺慢查詢的服務(wù)，這里的 10 是可以由業(yè)務(wù)自己定義，想定義多少都可以，以秒為單位，定義值的選擇，需要慎重考慮清楚，可以參考業(yè)務(wù)正常執(zhí)行的歷史時(shí)間，也可以參考業(yè)務(wù)流程最大容忍的正常時(shí)間，大致設(shè)置一個(gè)值就行，因?yàn)楫?dāng)出現(xiàn)異常情況的時(shí)候，這個(gè)語(yǔ)句需要執(zhí)行的時(shí)間肯定都會(huì)比這個(gè)大不少，肯定就被殺掉了。當(dāng)然如果設(shè)置太大，導(dǎo)致沒(méi)有殺掉，也是有問(wèn)題的，以秒為單位設(shè)置的話，殺慢查詢是不是及時(shí)還要決定于數(shù)據(jù)庫(kù)后臺(tái)殺慢查詢程序的執(zhí)行頻率，如果 5 秒一次的話，那就精度是 5 秒，如果是1秒一次的話，精度就是 1 秒，可以自由控制。

4）后面 “app comments” 部分，業(yè)務(wù)程序就可以隨便寫了，Agent 也不會(huì)做解析，也可以不寫，主要用來(lái)做一些注釋功能。

下面再說(shuō)一下這種方式的好處與缺點(diǎn)：

1） 精確： 很明顯，這種辦法是具體到了語(yǔ)句級(jí)別，誰(shuí)想要使用這樣的服務(wù)，就在語(yǔ)句前面做簽名，寫上時(shí)間，不寫的不會(huì)被殺掉。因?yàn)橛泻灻?，遵守了相關(guān)協(xié)議，業(yè)務(wù)程序和 DB 之間不存在責(zé)任界定不清楚的問(wèn)題，合作可以很愉快。

2） 常態(tài)化： 這種辦法就可以在數(shù)據(jù)庫(kù)本機(jī)部署一個(gè) Agent，專門每隔幾秒去檢查一次數(shù)據(jù)庫(kù)執(zhí)行情況，如果能匹配到慢查詢就殺，匹配不到就白跑一次，動(dòng)作輕量，影響不大，可以有效避免問(wèn)題的出現(xiàn)。

3）風(fēng)險(xiǎn)有效控制： 當(dāng)匹配到了需要?dú)⒌恼Z(yǔ)句之后，也可以放心地殺掉，因?yàn)檫@是業(yè)務(wù)根據(jù)自己的邏輯及預(yù)期設(shè)置好的時(shí)間，即使被殺了，也是不會(huì)有問(wèn)題的，風(fēng)險(xiǎn)可控，關(guān)鍵是可以避免異常語(yǔ)句引起的問(wèn)題，因?yàn)槲覀儦⒙樵兊哪繕?biāo)，就是要處理異常情況的慢查詢。

4）業(yè)務(wù)決定： 業(yè)務(wù)做了自己擅長(zhǎng)的事情，DBA 在這個(gè)過(guò)程中沒(méi)有任何決策的工作，是一個(gè)雙贏的局面。

5）效率高： 相比上面的方式，這種方式的配置都在 SQL 語(yǔ)句中，并且只有一個(gè)執(zhí)行時(shí)間值，非常容易解析出來(lái)，并且大部分情況下，數(shù)據(jù)庫(kù)狀態(tài)都是正常的，并沒(méi)有什么語(yǔ)句需要?dú)⒌舻模孕适欠浅８叩?。Agent 本身并不需要依賴其它模塊，簡(jiǎn)單易推廣。

6）誤殺： 這種辦法存在的唯一風(fēng)險(xiǎn)是，殺一個(gè)語(yǔ)句使用的是 connection id，當(dāng)匹配到一個(gè)需要?dú)⒌舻恼Z(yǔ)句之后，在執(zhí)行 kill 動(dòng)作時(shí)，這個(gè)語(yǔ)句正好執(zhí)行完了，而此時(shí)正好這個(gè) connection 執(zhí)行了一個(gè)新的語(yǔ)句，殺掉的時(shí)候并不知道是新的語(yǔ)句，此時(shí)被殺掉的是新語(yǔ)句，從而導(dǎo)致了誤殺，但實(shí)際上應(yīng)該想想，這種概率是非常小的，在匹配到與殺之時(shí)，時(shí)間差應(yīng)該是幾毫秒，在這幾毫秒的窗口內(nèi)，誤殺的概率可以忽略不計(jì)，但這是一種潛在風(fēng)險(xiǎn)，需要提前考慮到。

7）推廣度： 這種方法是有接入門檻的，但實(shí)際上門檻高度有限，如果所有業(yè)務(wù)都能接入的話，數(shù)據(jù)庫(kù)整體運(yùn)行就會(huì)很流暢，異常問(wèn)題都會(huì)提前發(fā)現(xiàn)與避免，不會(huì)再出現(xiàn)大的雪崩效應(yīng)，當(dāng)然這個(gè)結(jié)論，還需要時(shí)間驗(yàn)證，并且還需要業(yè)務(wù)填的時(shí)間相對(duì)合理才行。

3.源碼制

還有一種辦法可以實(shí)現(xiàn)這種功能，就是通過(guò)修改 MySQL 源代碼來(lái)實(shí)現(xiàn)，其實(shí)業(yè)內(nèi)已經(jīng)有一些這樣的團(tuán)隊(duì)做了這樣的事情，但最基本的邏輯還是沒(méi)變的，需要業(yè)務(wù)開(kāi)發(fā)自己在 SQL 語(yǔ)句中設(shè)置超時(shí)時(shí)間值，Mysql 服務(wù)執(zhí)行的時(shí)候通過(guò)解析語(yǔ)句發(fā)現(xiàn)設(shè)置了這個(gè)值，就會(huì)在執(zhí)行的過(guò)程中不斷檢查已經(jīng)執(zhí)行的時(shí)間，如果超過(guò)所設(shè)置的時(shí)間了，就會(huì)將其殺掉，從而實(shí)現(xiàn)了這樣的 SQL 語(yǔ)句執(zhí)行超時(shí)的機(jī)制。

但很明顯，這樣的實(shí)現(xiàn)方式，門檻非常高，需要修改源碼，不斷維護(hù)源碼，很少有人能做到這樣，并且我認(rèn)為，運(yùn)維和使用 MySQL 的過(guò)程中，如果有啥需求，能通過(guò) MySQL 的原生方法就能解決掉的（外圍辦法），就不要去改源碼來(lái)解決，因?yàn)橥ㄟ^(guò)外圍辦法解決的話，風(fēng)險(xiǎn)度會(huì)小很多，并且自由可控，不需要對(duì) MySQL 服務(wù)本身做過(guò)多干預(yù)，解決過(guò)程很輕量，易用。

五、總結(jié)

綜上所述，殺慢查詢還是需要非常謹(jǐn)慎的，提供服務(wù)是第一原因，所以既需要保證殺的準(zhǔn)確，也需要保證殺的及時(shí)，還需要保證不能殺出來(lái)問(wèn)題，所以這事情本身是一個(gè)很復(fù)雜的問(wèn)題。

上面推薦的這種解決辦法，實(shí)際上就是在給一個(gè) SQL 語(yǔ)句設(shè)置一個(gè)相對(duì)合理的超時(shí)時(shí)間，這是非常容易理解的，大家可以想想，寫代碼的時(shí)候，超時(shí)時(shí)間不都是隨處可見(jiàn)的嗎？如果能給 SQL 語(yǔ)句也設(shè)置一個(gè)超時(shí)時(shí)間，這樣可以更好的保護(hù)數(shù)據(jù)庫(kù)的穩(wěn)健運(yùn)行，那何樂(lè)而不為呢？

DBA 是一個(gè)服務(wù)性質(zhì)的工種，也非常想替業(yè)務(wù)解決一些頭疼的問(wèn)題，但解決問(wèn)題的時(shí)候，不能只見(jiàn)樹(shù)木不見(jiàn)森林，需要站在一定高度去看待問(wèn)題，需要找到合適的方法才能很好的解決問(wèn)題，不然有可能就是在創(chuàng)造問(wèn)題，找到了好的方法，通常就可以達(dá)到事半功倍的效果。

把復(fù)雜問(wèn)題簡(jiǎn)單化，業(yè)務(wù)去做自己擅長(zhǎng)的工作，DBA 也去做自己力所能及的工作，分工明確，合作共贏，長(zhǎng)久下去，一定可以建立一個(gè)穩(wěn)定、健康和良好的服務(wù)環(huán)境。

作者介紹

王竹峰， 去哪兒網(wǎng)數(shù)據(jù)庫(kù)總監(jiān)。擅長(zhǎng)數(shù)據(jù)庫(kù)開(kāi)發(fā)、數(shù)據(jù)庫(kù)管理及維護(hù)，一直致力于 MySQL 數(shù)據(jù)庫(kù)源碼的研究與探索，對(duì)數(shù)據(jù)庫(kù)原理及實(shí)現(xiàn)有深刻的理解。曾就職于達(dá)夢(mèng)數(shù)據(jù)庫(kù)，從事多年數(shù)據(jù)庫(kù)內(nèi)核開(kāi)發(fā)工作，后轉(zhuǎn)戰(zhàn)人人網(wǎng)，任職高級(jí)數(shù)據(jù)庫(kù)工程師，目前在去哪兒網(wǎng)負(fù)責(zé) MySQL 源碼研究與運(yùn)維、數(shù)據(jù)庫(kù)管理和自動(dòng)化運(yùn)維平臺(tái)設(shè)計(jì)開(kāi)發(fā)及實(shí)踐工作，是 Inception 開(kāi)源項(xiàng)目及《MySQL運(yùn)維內(nèi)參》的作者， MySQL 方向的 Oracle ACE。