MySQL 優化腳本（analyze）引發的應用崩潰

早上剛走進公司的門口，快走到辦公桌的時候，開發的同事很着急的跟我說：你可來了！

我：發生什麼事情了？

開發同事：XX數據庫死掉了！

我：特別驚訝！這個庫運行的一直的很好的，怎麼會死掉了？何況也沒有接收到監控的報警信息？

      彆着急，等我遠程鏈接上去看看。

登錄到MySQL後查看一下狀態： show processlist；

而後看到至少有一千多個查詢一直在執行，根據以往的經驗是有鎖出現了，致使後來的查詢被阻塞掉了，因此應用這邊就崩潰了，返回了超時的錯誤！

仔細一看顯示的單個SQL查詢的狀態大部分都是：.....Query26037Waiting for table flushSELECT.......

注意紅色字體的關鍵字，官網的解釋是：

Flushing tables

The thread is executing FLUSH TABLES and is waiting for all threads to close their tables.

也就是說線程執行刷新表操做而且等待全部的線程關閉他們佔用的表。

一個超長執行時間的SQL被發現了，這個SQL大概執行了十幾個小時尚未查出結果。

可是這樣也不該該回引發flush tables 的問題出現。

kill 掉這個SQL線程以後，慢慢的系統恢復了正常查詢的狀態。

就這樣粗暴的處理完成以後，就看系統各類的日誌，開始查找緣由，忽然想到今天是週末

對呀週末！！

週末會怎樣呢？

週末有一個優化腳本任務執行的！

這個優化腳本就是使用analyze去分析每張表，analyze會收集表的統計信息。

會致使mysql檢測到對應的table作了修改，必須執行flush操做，close和reopen表

由此能夠推斷出，是由於那個執行時間超長的SQL在執行過程當中，個人優化腳本任務也啓動了，對SQL佔用的表進行了analyze 那張表就須要被close和reopen。可是SQL寫的太爛，一直沒有執行完成，也就不能釋放對錶的佔用。以致於後面的SQL就要排隊等待。

只要將那個SQL給kill掉就關閉了表，而後續的SQL就從新打開了那個表，正常！

我根據推斷作了一個測試，首先手工執行那個爛SQL等待了一下子沒有查出結果的跡象，在這個時候使用analyze table table_name;

show processlit 查看狀態，果真如此！截圖中紅色框部分

實驗證實了是analyze引發的問題，但不是主要的問題。

因而和開發商量須要改進SQL進行優化。搞定！