tidb-一场select in百万参数引发的血案

一、背景

最近的tidb突然出现了写入极慢的原因,这时候就要排查下为什么了,我们一步步看看解决的方法

二、排查

整体写入慢的排查思路可以看下官网

1.解决中

我们按照排查步骤一步步排查,最重要的监控就是查看raft io了,这里可以看到commit的耗时严重异常

tikv details -> raft io -> commit log duration
在这里插入图片描述

那么这个耗时为什么会这么长,这就需要排查慢日志了,慢日志的排插,排查出一些写入的sql后我们发现了下面这条主要的sql

select a,b,c from table_a where info="456" and info_id in (123,45,6,3453,4534,....,sdfs) group by abc

这个问题的重点是in里面有上百万个参数,而这个大的慢sql又导致了执行计划超过1G,这个慢查询写入到日志里就会占用大量的磁盘性能,调用查看慢查询的时候也会占用大量磁盘的性能,而tidb和tikv也有一台机器进行了混步,整体的raft log同步也会变得较慢

2.解决后

现在我们看看将这条sql优化后的情况,可以看到commit log的耗时已经变得非常低了,这时候我们的写入也变得正常了
在这里插入图片描述

三、总结

当然,中间的排查结果并不是这么顺利的,调整了很多参数,都没有太起作用,最后才定位到这个慢sql,主要是没有想到这个慢sql的执行计划这么大,造成了如此大的影响

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值