MySQL中insert语句没有响应的问题剖析
发布时间：2022-04-05 23:06:34 所属栏目：MySql教程 来源：互联网
导读：今天开发的一个同学问我一个MySQL的问题，说在测试数据库中执行一条Insert语句之后很久没有响应。我一看语句是一个很常规的insert into xxx values形式的语句。看起来有些不太合乎常理啊，我对这类问题立马来了兴趣，准备好好看看到底是什么原因。 向开发同
|
今天开发的一个同学问我一个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了。 （编辑：拼字网 - 核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐