作者： Jasper 原文来源：https://tidb.net/blog/24b5f288

问题背景

热力图显示某张表读流量达到 60G/min , 有明显的热点问题。

排查过程

1. 热力图已经给了表名，第一反应其实就是根据 慢查询、sql 语句分析等方式定位相关 sql，但是都没找到有读相关的 sql ，根据业务反馈该张表上也没有读相关的业务。

1. 那会不会是流量统计异常呢？ 根据问题时间点查看 tikv 的相关监控查找热点情况，可以看到 15:00 - 16:00 有两个 tikv 明显 cpu 偏高。

1. 那么再根据看下 这个 tikv 上的 read flow，发现明显高于正常水平。 尖刺时间点平均 1g/S 1g *60 差不多 60g/min，和热力图的流量是可以对得上的。 说明热力图显示没问题。

1. 既然从表名查不出，那么换个思路，根据 region 去查呢？从热力图给出的 startkey 和 endkey 先定位 region_id，查询方式如下：

查询结果 key 所在 region 为 1439658 ：

1. 再通过 region id 1439658 查找相关表名。

根据 region 定位相关表

查询方式如下:

select a.table_name,a.read_bytes/1024/1024/1024from information_schema.tables a , information_schema.TIKV_REGION_STATUS bwhere a.tidb_table_id=b.table_id and b.region_id=1439658;

查询结果如下，可以看到我们 dashboard 中显示的 risk_xxx 只是其中之一

1. 既然已经查到 两个热点的 tikv 了，那么我们可以通过 dashboard 的 top sql ，选择具体的 tikv 来定位热点 sql，通过这种方式定位到了 cb_label 表在问题时间段有大量全表扫描 sql

1. 添加合适的索引后，问题消失。

相关原理

1. dashboard 热力图中显示的表热点所在 region 恰好落在 region 边界上的表，故此当一个 region 存在多张表的情况下，可能存在 热力图 显示表不准的情况发生。

2. 相关热点问题可以通过 tikv_region_status , pd-ctl 方式确认流量变高的具体原因。

预期情况下，以下三种方式查询到的流量保持一致

• Dashboard 中热力图显示的 region 流量 (可根据图中 startkey，结合 pd-ctl 定位具体 region_id

• tikv_region_status 中的 read_bytes 字段， 注意该字段只统计最近一分钟的 region 读流量。

• pd-ctl region xxx 命令中的 read_bytes

1. 热点问题定位到相关 region 及相关表之后，可结合 top sql 、 慢查询、sql 语句分析进一步定位相关 sql