教你快准狠上手基于 Dashboard 快速定位问题 SQL

作者： hzc989 原文来源：https://tidb.net/blog/3a51486c

问题背景

3 月的最后一周，公司的 DW TiDB 出现多次 Tiflash 电话告警，周末也有好几次，暂时还没有收到有业务反馈受到影响。

基于 slow query 的排查过程

首先作为 DBA，入手排查第一思路都是先看看异常期间有没慢查询，于是万能慢查排查语句又来了~

依次对比了各个时间段出现的告警和慢查询的告警时间，并未发现吻合的地方。

到此，慢查询这条路子也就暂无思路，走不通了。

基于 Dashboard 的排查过程

正当思路卡点的时候，突然想到了 TiDB Dashboard 神器，尤其是 6.0 版本以来推出的 Top SQL ，个人认为堪称 TiDB DBA 排查神器中的神器。

我先是在监控指标页多处搜刮图表，寻找符合告警时间段内的噪点，其中一个延迟拆解图表引人注目般映入眼帘 ，告警期间的 DELETE 的耗时尤其明显

另一边厢再仔细看，官方文档对此告警的解释，格局打开，或许与 TiKV Store 繁忙相关

read index is the kvproto request sent to the TiKV leader. TiKV region retries, busy store, or network problems might lead to long request time of read index.

于是开始在 Top SQL 界面逐个搜寻击破之路 …

TopSQL 能够做到支持按 TiDB server、TiKV Store ，以时间字段区分来展示该节点上的 Top SQL 。

我先是简单在几个 TiDB server 节点，没有发现太大收获。这种情况，也是和之前在 Slow Query 上定位未有发现的情况相符合，这大概率不是一个直接的、字面意义上的慢查询。

于是开始搜寻 TiKV，果然在搜寻第一个 TiKV 节点的时候，就定位到了这条 DELETE 的特征，它的累计使用 CPU 时间冲到了第一，并且它有异常多的执行计划（看到最多的时候，多达 60+ 的恐怖量）

而且关键是，查阅近一周的告警事件段，每次当出现上面的 TiFlash Read Index 告警的时候，这些 DELETE 都是这样冲到最前面。

接着使用 SQL 语句分析（这又是另外一个神器），对这个 DELETE 进行分析，发现都是同一个库的几个 DELETE 语句耗时特别严重

点进去可以看到这个 SQL Pattern，并且可以知道执行计划，执行用户等信息。

它是一个 IN 多行 DELETE，是我们的 DM 同步任务产生的，而我们 DM syncer 开启了 Multiple-rows=True 特性，这个行为就体现成多行 DELETE 了。

直觉告诉我，这大概率是一个 DELETE 大范围（比如一年）或者甚至是不带 WHERE 的 DELETE 全表操作。

于是上 DM Worker 找到 relay-log 日志下的 binlog，果然实锤了，接下来就是找研发处理的事情去了。