故障案例--寻找瓶颈SQL的一种方法

故障现象

DB响应非常慢,连接数暴涨直到打满;

任何SQL看起来都是慢查询,都要几十秒以上;

show  processlist时SQL种类非常多,短时间无法分辨哪个是引起故障的SQL,挑了几个看SQL问题不大;

CPU,IO都非常低,看样子无系统瓶颈,也无任何硬件层面的报错;

故障原因和定位方法

猜测是高并发引起的性能瓶颈,通过show engine innodb status\G结果看存在大量的sleeping before entering InnoDB,也就是说大量的SQL没法进入innodb内部执行,存在排队现象,从而导致这些原本没问题的SQL也都变成了慢查询。

一开始怀疑是innodb_thread_concurrency的问题,发现参数设置较为合理,排除这个原因;

发现show  engine innodb status\G中的事务还能查看当前正在innodb内部执行的SQL,通过搜索关键词inside Innodb即可,数量正好与innodb_thread_concurrency相当,于是确定就是这个SQL引起的,发现这个SQL就是无脑的select * from XX的全表扫描,下线该SQL后问题得到解决


  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值