MySQL中insert語句沒有響應的問題分析(r11筆記第21天)

 今天開發的一個同學問我一個MySQL的問題，說在測試資料庫中執行一條Insert語句之後很久沒有響應。我一看語句是一個很常規的insert into xxx values形式的語句。看起來有些不太合乎常理啊，我對這類問題立馬來了興趣，準備好好看看到底是什麼原因。

 向開發同學瞭解了環境之後，我登入到服務端，首先檢視是否可能是磁碟空間不足導致的問題。結果df -h的結果顯示，空間還綽綽有餘。

使用show proceslist檢視執行緒情況。

可以看到大量的執行緒是Waiting for table level lock ,開發同學提交的SQL語句也被鎖住了，也是同樣的鎖。

| 253688 | webadmin | xxxx   | pt_test | Query   |    171 | Waiting for table level lock | insert into ptp_jgg(sub_type) values(9999)這類表級鎖好像在MyISAM中還是看到過，結果檢視錶的儲存引擎，發現都是InnoDB,

對於這類問題的一種解決方法，就是使用kill的方式殺掉執行緒。

mysql> SELECT
    ->  a.*,CONCAT("kill " ,a.id,";")
    -> FROM
    ->  information_schema.`PROCESSLIST` a
    -> WHERE
    ->  a.STATE = 'Waiting for table level lock';

 這樣就會生成很規律的kill語句。

當然我也沒有著急這麼做，和開發同學簡單瞭解，他們之前碰到這類問題，是找系統運維的同學直接重啟MySQL的，看來這個問題之前也碰到過，這我就更有興趣瞭解了。

檢視MySQL的error log也沒有發現什麼明顯的錯誤，使用ps -ef|grep mysql檢視程式的資訊，突然發現系統中是設定了一個定時任務去備份資料，不過開始沒有引起我的注意，但是這些線索都逐一排除之後，我的注意力就很自然的落在了這個備份指令碼上。

開啟備份指令碼，我就明白問題的原委了。

備份的核心語句是透過變數的方式呼叫mysqldump的。

mysqldump -uroot -p$passwd pt_test | $GZIP -9 > $dump_path/pt_test$date.gz

這樣一來這個語句毫無疑問就是這個鎖表的罪魁禍首。

預設mysqldump會呼叫--lock-all-tables這個選項，也就意味著master的binlog和postion資訊寫入SQL檔案的頭部，而通用的方式是使用--single-transaction

執行的時候會有短暫的全域性讀鎖，影響要低得多。

    所以這個問題的解決方式就很直接，當前解決就是直接kill掉正在進行的mysqldump，殺掉備份的mysqldump之後，再次檢視show processlist，這些執行緒馬上就是sleep狀態了。

    這樣一來，這個問題就算是基本解決了，我想以後至少不會因為這樣而無端重啟MySQL了。