请问tidb如何锁定当前引起CPU负载高的SQL

随缘天空 · 2026 年5 月 22 日 01:41

是的，正常情况下正在执行的sql可以查到，但是慢sql监控面板统计的都是已经执行完的sql，尚在进行中的只能到日志文件中查看

TiDBer_1834 · 2026 年5 月 22 日 08:51

看一下TOPSQL,不过看起来有热块

TiDB001 · 2026 年5 月 22 日 14:38

看上去是遇到了热点问题

yg_2024 · 2026 年5 月 25 日 01:06

看下画箭头的哪块，对应了哪个对象，从发上来的截图上，看着这行数据是最亮的。既然是tikv打满了，那就看看哪个对象读写量大，然后在去找包含这个对象的慢SQL。

yg_2024 · 2026 年5 月 25 日 01:09

另外，从截图上看，top10的SQL前面都一样，那就有点怀疑，这类是高频执行的SQL（页面首页自动执行），同时执行计划跑偏了。

炼气期DBA · 2026 年5 月 25 日 02:33

今天早上又遇到卡的问题。截图了一周的热点。这几个绿框里的亮度是不是表明都存在热点呢？

yg_2024 · 2026 年5 月 25 日 02:42

都有嫌疑。
这个图亮条，多了反倒抓不到重点。有一些表什么时候都是亮的（业务快的时候也亮），这些可以先排除。主要还是看，业务慢的时候，那些亮条是新出现的。

独善其身 · 2026 年5 月 26 日 01:53

看看最热的sql执行计划

TiDB001 · 2026 年5 月 26 日 13:28

看上去没有明显的慢sql，是不是流量突然上长，延时有没有增加？

炼气期DBA · 2026 年5 月 27 日 01:44

最后总结一句，tidb监控真娘的是鸡勒，完全无法确定是哪条SQL是导致CPU增长的，什么慢查询，什么SQL语句分析，什么TOP SQL，扯蛋，最终你会发现，这3个东西不能捕猎到一致点，最后你自己都迷糊了。

独善其身 · 2026 年5 月 27 日 02:04

这句话说的比较贴切,出问题只能做问题定性,仔细分析还得靠内部字典

WalterWj · 2026 年5 月 27 日 02:14

这个 tikv 就是 cpu 高的么？
非这个时间段的 QPS 是多少？

炼气期DBA · 2026 年5 月 27 日 02:38

取了２天这个时间点的qps

WalterWj · 2026 年5 月 27 日 02:58

我是想问你，在 tikv cpu 飙高的对应时间前后，QPS 有明显上涨么。
如果有可能就是单纯 QPS 高导致的压力大。

监控上看一个 tikv cpu 高，而且是 read pool。那说明是读热点。

top sql 的图，tikv 选择的是 cpu 高的节点么，截图上来看，other 的含义是非 TOP 5 SQL，其他 SQL 占比 CPU 高。说明多数压力来自很多 SQL ，不是一个模式的 SQL。

有个老方法，你去对应 tikv 节点看日志，匹配关键字 slow-query .里面有一些 region 信息，看看 region 属于什么表的，反找对应表对应时间的 SQL。
看看查询条件和业务模型什么样的。

下次遇到这个情况，热力图选择频次看看能不能看出啥。