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

炼气期DBA · 2026 年5 月 18 日 06:45

请问tidb如何锁定当前引起CPU负载高的SQL？
9点-10点期间，tikv CPU爆了，从监控里看到有慢sql，select a.payclass…sum(a.pay…)

但连接数据库执行showprocesslist根本就找不到这条SQL，而且也不是这条SQL引起的问题，但监控里看到像是这条SQL引起的CPU持续占用高原因。

我已经对这监控持怀疑态度。

Circle · 2026 年5 月 18 日 08:03

可以再结合 Dashboard 的流量可视化，看下当时哪个表的读流量高。再去 SQL 语句分析下/慢日志中找这个表的相关查询。

wbslxw · 2026 年5 月 18 日 08:05

会不会是高频短 SQL：单次执行很快，结束后立刻退出

TiDBer_odwPM8gO · 2026 年5 月 18 日 08:06

楼上说的有道理，即使 SQL 本身不慢，高频次的累积 CPU 耗时也会打满 TiKV

zhanggame1 · 2026 年5 月 18 日 08:35

show processlist 看不到正常啊你用这个看
select * from INFORMATION_SCHEMA.CLUSTER_PROCESSLIST t
where t.COMMAND<>‘Sleep’

炼气期DBA · 2026 年5 月 18 日 08:59

这流量看视图，看出哪个地方有问题呢？

Raymond · 2026 年5 月 18 日 14:42

楼主，看你的图里面的unified read pool cpu高的话，大概率还是读慢sql导致的，你去打开tidb集群的top sql 功能，就可以看到哪个sql导致的了，你可以官网搜下top sql 功能

炼气期DBA · 2026 年5 月 19 日 01:12

我是登录那台CPU占用高的节点上执行show processlist,不需要使用cluster_processlist吧？

炼气期DBA · 2026 年5 月 19 日 01:15

第3张图就是top sql啊，这里显示的top sql根本不是引起当前CPU增长的SQL，所以说这里的top sql绝大多数行同虚设，突发的SQL根本就捕获不到这里来，不知道这个监控是怎么监控的。

独善其身 · 2026 年5 月 19 日 01:51

看图上排第一的sql也只是执行了一次吧

炼气期DBA · 2026 年5 月 19 日 02:01

可是第2张图里，显示很多这条SQL啊。

克里克里克 · 2026 年5 月 19 日 02:15

大概率还是那个慢SQL，可以对比下慢SQL和以前的执行频次以及消耗是否有差异，如果执行效率没什么差异，那有可能就是慢SQL的并发上来将CPU打满了。

Augenstern · 2026 年5 月 19 日 03:23

重点看下慢SQL

TiDBer_jYQINSnf · 2026 年5 月 19 日 03:32

看看tikv的 grpc请求，哪个种类的多。也看看 tikv 的日志，看看在输出什么。

炼气期DBA · 2026 年5 月 19 日 05:50

我也觉得大概像是那个SQL，但是showprocesslist没有看到有执行这条语句，奇怪，只看到另一条count(*)有好几个会话在执行。

TiDBer_aaaaa · 2026 年5 月 20 日 02:37

监控显示的是 “历史慢查询”，不是实时运行的 SQL

CHENGX · 2026 年5 月 20 日 06:59

SELECT * FROM information_schema.cluster_processlist
WHERE COMMAND != ‘Sleep’ order by MEM desc;看一下看一下出现比较频繁的sql

随缘天空 · 2026 年5 月 20 日 09:19

这种只能查看正在操作的进程，如果执行完了，就查不到sql信息

炼气期DBA · 2026 年5 月 22 日 01:08

这么慢的SQL，不可能一下子执行完，监控里显示平均耗时29.4s，show processlist看不到，这就有点奇葩了。

TiDBer_00001 · 2026 年5 月 22 日 01:29

那有日志能看到吗？