前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >MySQL中insert语句没有响应的问题分析(r11笔记第21天)

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

作者头像
jeanron100
发布2018-03-21 11:24:36
1.2K0
发布2018-03-21 11:24:36
举报
文章被收录于专栏:杨建荣的学习笔记

今天开发的一个同学问我一个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的方式杀掉线程。

代码语言:javascript
复制
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了。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2016-12-22,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 杨建荣的学习笔记 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
云数据库 MySQL
腾讯云数据库 MySQL(TencentDB for MySQL)为用户提供安全可靠,性能卓越、易于维护的企业级云数据库服务。其具备6大企业级特性,包括企业级定制内核、企业级高可用、企业级高可靠、企业级安全、企业级扩展以及企业级智能运维。通过使用腾讯云数据库 MySQL,可实现分钟级别的数据库部署、弹性扩展以及全自动化的运维管理,不仅经济实惠,而且稳定可靠,易于运维。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档