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

相关推荐
geinvse_seg1 小时前
飞算JavaAI:把企业采购协同需求拆成一套可运行的慧采平台
java·ai·飞算
起予者汝也1 小时前
Python 数据结构
开发语言·数据结构·python
烛影摇红透纱窗3 小时前
ForkJoinPool 与工作窃取
java
浩瀚地学3 小时前
【面试算法笔记】0302-哈希表-哈希表实现
java·经验分享·笔记·算法·面试
ECT-OS-JiuHuaShan3 小时前
严格证明:还原论是ASCII,整体论是UTF-8的历史意义和价值
开发语言·人工智能·算法·量子计算
AC赳赳老秦3 小时前
时间开销自动统计:OpenClaw 记录工作任务时长、分析时间分配、给出优化建议
java·大数据·开发语言·python·自动化·deepseek·openclaw
祉猷并茂,雯华若锦4 小时前
Appium 3.x 实战:元素定位与常见错误解析
开发语言·python·appium
名侦探7224 小时前
构建 Agent 的五大难点与解决方案
java·大数据·人工智能
Demons_kirit4 小时前
图库原理(以阿里云OSS为案例)
java·阿里云·云计算
SimonKing4 小时前
那个号称"对标 Spring"的国产框架 Solon,到底行不行?
java·后端·程序员