今天開發(fā)的一個同學(xué)問我一個MySQL的問題，說在測試數(shù)據(jù)庫中執(zhí)行一條Insert語句之后很久沒有響應(yīng)。我一看語句是一個很常規(guī)的insert into xxx values形式的語句?？雌饋碛行┎惶虾醭＠戆?，我對這類問題立馬來了興趣，準(zhǔn)備好好看看到底是什么原因。

作為一家“創(chuàng)意+整合+營銷”的成都網(wǎng)站建設(shè)機(jī)構(gòu)，我們在業(yè)內(nèi)良好的客戶口碑。創(chuàng)新互聯(lián)公司提供從前期的網(wǎng)站品牌分析策劃、網(wǎng)站設(shè)計、網(wǎng)站設(shè)計制作、成都做網(wǎng)站、創(chuàng)意表現(xiàn)、網(wǎng)頁制作、系統(tǒng)開發(fā)以及后續(xù)網(wǎng)站營銷運(yùn)營等一系列服務(wù)，幫助企業(yè)打造創(chuàng)新的互聯(lián)網(wǎng)品牌經(jīng)營模式與有效的網(wǎng)絡(luò)營銷方法,創(chuàng)造更大的價值。

 向開發(fā)同學(xué)了解了環(huán)境之后，我登錄到服務(wù)端，首先查看是否可能是磁盤空間不足導(dǎo)致的問題。結(jié)果df -h的結(jié)果顯示，空間還綽綽有余。

使用show proceslist查看線程情況。

可以看到大量的線程是Waiting for table level lock ,開發(fā)同學(xué)提交的SQL語句也被鎖住了，也是同樣的鎖。

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

對于這類問題的一種解決方法，就是使用kill的方式殺掉線程。

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

 這樣就會生成很規(guī)律的kill語句。

當(dāng)然我也沒有著急這么做，和開發(fā)同學(xué)簡單了解，他們之前碰到這類問題，是找系統(tǒng)運(yùn)維的同學(xué)直接重啟MySQL的，看來這個問題之前也碰到過，這我就更有興趣了解了。

查看MySQL的error log也沒有發(fā)現(xiàn)什么明顯的錯誤，使用ps -ef|grep mysql查看進(jìn)程的信息，突然發(fā)現(xiàn)系統(tǒng)中是設(shè)置了一個定時任務(wù)去備份數(shù)據(jù)，不過開始沒有引起我的注意，但是這些線索都逐一排除之后，我的注意力就很自然的落在了這個備份腳本上。

打開備份腳本，我就明白問題的原委了。

備份的核心語句是通過變量的方式調(diào)用mysqldump的。

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

這樣一來這個語句毫無疑問就是這個鎖表的罪魁禍?zhǔn)住?/p>

默認(rèn)mysqldump會調(diào)用--lock-all-tables這個選項(xiàng)，也就意味著master的binlog和postion信息寫入SQL文件的頭部，而通用的方式是使用--single-transaction

執(zhí)行的時候會有短暫的全局讀鎖，影響要低得多。

    所以這個問題的解決方式就很直接，當(dāng)前解決就是直接kill掉正在進(jìn)行的mysqldump，殺掉備份的mysqldump之后，再次查看show processlist，這些線程馬上就是sleep狀態(tài)了。

    這樣一來，這個問題就算是基本解決了，我想以后至少不會因?yàn)檫@樣而無端重啟MySQL了。