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進行優化。搞定！

     本文轉自andylhz 51CTO部落格，原文連結：http://blog.51cto.com/andylhz2009/1354890，如需轉載請自行聯系原作者