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