這個mysql資料庫是佇列資料庫,5.5.21版本，用於頻繁的增刪查操作。平時使用正常，但是在16日凌晨資料庫伺服器wait IO突然增高，由原來的7%飆到了34%。導致很多連線一直都處於等待狀態。

1、排查了已知的配置引數，沒有什麼變動，配置也正常，沒有離譜的。

2、又檢查了索引，也是之前的操作，沒有多大的變動。

3、後來又查詢了慢語句，發現都是平時執行的那些普通的sql，沒有特殊的。

4、網路有問題？異地操作和本地操作也沒有多大變化，ping的響應時間也0.1ms左右。

5、分析之後又瞭解到普遍寫很慢，平均等待大約得3-6s，哪怕是簡單的根據主鍵刪除操作；select讀取操作倒是很快。

6、伺服器問題？檢查硬碟空間，才使用8%，raid也正常。SA人員說硬碟和cpu等正常，沒與問題。

後來因為業務不熟，認為資料量又增大了，是引數的配置問題，就一直尋找mysql的關鍵引數，調整引數。

重啟資料庫過程中不能正常stop，即使啟動了也報正常啟動。認為不影響使用,是指令碼的問題，就把這個問題跳過了。

查詢了一天半夜都沒有找到原因，個別的已經積壓了將近千萬的資料庫了。。。

第二天再弄。

又查詢引數，查詢機器，都麼有查詢到任何問題。

都沒有問題，暈死了。

換吧，換其他機器。半夜的時候打算換庫，只聽到有8個程式操作庫，wait io還是在20%左右，然後把這8個程式操作的資料庫該為新的庫（資料、引數等都一樣），wait io只有5%！！！

回想起原來資料庫重啟都有問題，在加上現在的情況，重灌資料庫。

 凌晨4點，解決了。。。

總結：

1、  細小的問題不要忽略，不要放過任何蛛絲馬跡。

2、  資料庫和伺服器的知識還是很欠缺，導致問題查詢不能完全排除，不夠自信，有返工現象。浪費時間。

3、  資料庫平時應該就做好資料備份，服務備用，找不到問題優先保證資料正常，不至於臨時抓瞎。平時多做準備工作。平時多流汗,戰時少流血。