请问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。
看看查询条件和业务模型什么样的。

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

TiDBer_1834 · 2026 年6 月 1 日 14:31

TiDB的慢查询日志可以帮助你找到执行时间长的查询。你可以在TiDB配置文件中启用慢查询日志，并设置适当的阈值

TiDB001 · 2026 年6 月 1 日 14:47

使用 TiDB 的监控工具（如 Prometheus 和 Grafana）来查看系统的整体负载情况，特别是 CPU 使用率。然后可以通过Dashboard进一步确定topsql

TiDBer_bgWIGhji · 2026 年6 月 2 日 01:32

TiDB 的 OOM 经常跟算子下推有关，比如 hash join 或 hash agg 在内存不足时不会 spill 到磁盘。从根本上说，建议从数据分布和查询模式入手，减少大表 JOIN 和全量扫描，利用 Region 级别的并行计算来分摊内存压力。

大唐天子 · 2026 年6 月 7 日 01:42

结合 Dashboard 流量监控视图，定位高读流量的数据表，再到 SQL 分析模块、慢查询日志 中，检索该表对应的执行语句，进一步排查问题。

TiDB_001 · 2026 年6 月 7 日 01:58

show processlist 仅查看当前连接的单个 TiDB 节点的前端会话，无法跨节点查看整个集群。如果 SQL 路由到其他 TiDB 节点执行，当前节点自然看不到。

社区给出标准解决方案：使用集群级视图 INFORMATION_SCHEMA.CLUSTER_PROCESSLIST，可查看全集群所有活跃会话。

聚合查询如果没有覆盖索引，TiKV 需要逐行读取数据、计算，产生海量 CPU 运算。这是聚合类 SQL CPU 高的最常见原因。

mtmt · 2026 年6 月 8 日 03:44

向高手学习思考逻辑