今天开发的一个同学问我一个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了。