MySQL中insert语句没有响应的问题分析(r11笔记第21天)

 今天开发的一个同学问我一个MySQL的问题,说在测试数据库中执行一条Insert语句之后很久没有响应。我一看语句是一个很常规的insert into xxx values形式的语句。看起来有些不太合乎常理啊,我对这类问题立马来了兴趣,准备好好看看到底是什么原因。

作为一家“创意+整合+营销”的成都网站建设机构,我们在业内良好的客户口碑。创新互联公司提供从前期的网站品牌分析策划、网站设计、网站设计制作、成都做网站、创意表现、网页制作、系统开发以及后续网站营销运营等一系列服务,帮助企业打造创新的互联网品牌经营模式与有效的网络营销方法,创造更大的价值。

 向开发同学了解了环境之后,我登录到服务端,首先查看是否可能是磁盘空间不足导致的问题。结果df -h的结果显示,空间还绰绰有余。

使用show proceslist查看线程情况。

MySQL中insert语句没有响应的问题分析(r11笔记第21天)
可以看到大量的线程是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了。


本文题目:MySQL中insert语句没有响应的问题分析(r11笔记第21天)
本文URL:http://scyanting.com/article/jjgegs.html