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

一、背景

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

二、排查

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

1.解决中

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

tikv details -> raft io -> commit log duration

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

bash 复制代码
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的执行计划这么大,造成了如此大的影响

相关推荐
xiaoye20182 小时前
Lettuce连接模型、命令执行、Pipeline 浅析
java
beata5 小时前
Java基础-18:Java开发中的常用设计模式:深入解析与实战应用
java·后端
Seven976 小时前
剑指offer-81、⼆叉搜索树的最近公共祖先
java
雨中飘荡的记忆1 天前
保证金系统入门到实战
java·后端
Nyarlathotep01131 天前
Java内存模型
java
暮色妖娆丶1 天前
不过是吃了几年互联网红利罢了,我高估了自己
java·后端·面试
NE_STOP1 天前
MyBatis-参数处理与查询结果映射
java
狂奔小菜鸡1 天前
Day40 | Java中的ReadWriteLock读写锁
java·后端·java ee
SimonKing1 天前
JetBrains 用户狂喜!这个 AI 插件让 IDE 原地进化成「智能编码助手」
java·后端·程序员