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

相关推荐
考虑考虑6 小时前
JDK26中的Map.ofLazy
java·后端·java ee
鶴哥只手遮天9 小时前
Spring AI 2.0.1 深度解析-第 14 章 MCP 服务端(上):注解式实现与工具来源
java·人工智能·开源
鶴哥只手遮天9 小时前
Spring AI 2.0.1 深度解析-第 15 章 MCP 服务端(下):三种协议形态、Streamable 传输与状态管理
java·人工智能·开源
鶴哥只手遮天9 小时前
Spring AI 2.0.1 深度解析-第 16 章 向量存储(上):`VectorStore` 接口体系、`BatchingStrategy`
java·人工智能·开源
鶴哥只手遮天9 小时前
Spring AI 2.0.1 深度解析-第 12 章 工具循环的流式形态、Usage 累加与扩展体系
java·人工智能·开源
鶴哥只手遮天10 小时前
Spring AI 2.0.1 深度解析-第 23 章 模型供应商实现:从 `OpenAiSetup` 到 Bedrock
java·人工智能·开源
鶴哥只手遮天10 小时前
Spring AI 2.0.1 深度解析-第 06 章 内置 Advisor 全景:13 个实现逐个剖到源码级
java·人工智能·开源
鶴哥只手遮天10 小时前
Spring AI 2.0.1 深度解析-第 03 章 消息体系与 Prompt:不可变模型、`ChatOptions` 与模板渲染
java·人工智能·开源
鶴哥只手遮天10 小时前
Spring AI 2.0.1 深度解析-第 24 章 生产实践与 2.x 迁移:陷阱清单、AOT 与调优
java·人工智能·开源
鶴哥只手遮天10 小时前
Spring AI 2.0.1 深度解析-第 10 章 工具调用(中):执行链路、结果转换与工具限制
java·人工智能·开源