[v8.5.3] 慢查询全是这个mysql.tidb_ddl_notifier，能优化吗

【TiDB 使用环境】生产环境
全是这个，能优化吗？

image1362×647 86.4 KB

image397×164 5.73 KB

执行计划

| id | estRows | estCost | actRows | task | access object | execution info | operator info | memory | disk |
| Limit_12 | 1024.00 | 171431.72 | 1024 | root | | time:1.3s, loops:2 | offset:0, count:1024 | N/A | N/A |
| └─TableReader_22 | 1024.00 | 171431.72 | 1024 | root | | time:1.3s, loops:1, cop_task: {num: 1, max: 763.9ms, proc_keys: 1024, tot_proc: 486ms, tot_wait: 53.3µs, copr_cache_hit_ratio: 0.00, build_task_duration: 24.9µs, max_distsql_concurrency: 1}, rpc_info:{Cop:{num_rpc:1, total_time:763.9ms}} | data:Limit_21 | 88.5 MB | N/A |
| └─Limit_21 | 1024.00 | 381754.13 | 1024 | cop[tikv] | | tikv_task:{time:234ms, loops:6}, scan_detail: {total_process_keys: 1024, total_process_keys_size: 90834509, total_keys: 1026, get_snapshot_time: 27.4µs, rocksdb: {key_skipped_count: 2047, block: {cache_hit_count: 913}}}, time_detail: {total_process_time: 486ms, total_suspend_time: 237.7µs, total_wait_time: 53.3µs, total_kv_read_wall_time: 234ms, tikv_wall_time: 486.5ms} | offset:0, count:1024 | N/A | N/A |
| └─TableRangeScan_20 | 1024.00 | 381754.13 | 1024 | cop[tikv] | table:tidb_ddl_notifier | tikv_task:{time:234ms, loops:6} | range:(0 0,0 +inf], (0,+inf], keep order:true | N/A | N/A |

有其他慢语句吗？如果表数量少还慢，那可能是资源不足或者其他慢语句导致的这个语句慢。

怎么会这么多

有别的慢查询，但不多。 慢查询页面首屏大部分都是这个
集群没什么压力

image1063×753 124 KB

改为增量查询

当前查询用固定条件(0, 0)扫描全表，需调整为基于上一次查询的最大值做增量过滤：

• 记录每次查询返回的最大(ddl_job_id, sub_job_id)（比如上一次结果的最大值是(X,Y)）；
• 下一次查询条件改为(ddl_job_id, sub_job_id) > (X,Y)，仅扫描新增的 DDL 事件。
• 效果：扫描数据量从 “全表” 缩减为 “新增记录”，执行时间和内存占用会显著降低。

降低查询执行频率

该查询通常是 TiDB 内部组件（如 CDC、DDL 通知模块）的轮询请求，可：

• 调整组件的轮询间隔（比如从 “秒级” 改为 “分钟级”，需结合业务对 DDL 同步的实时性要求）；
• 避免短时间内重复触发该查询（比如截图中短时间内多次执行）。

验证执行计划的索引利用

mysql.tidb_ddl_notifier的主键是(ddl_job_id, sub_job_id)，当前执行计划的TableRangeScan实际是主键索引的范围扫描（聚簇索引下等价于索引扫描），但需确认 TiDB v8.5.3 是否有优化空间：

• 检查是否存在参数可调整索引扫描的效率（如tidb_opt_range_scan）；
• 若仍存在全表扫描，可通过ANALYZE TABLE mysql.tidb_ddl_notifier;更新表统计信息，帮助优化器选择更优计划。

有频繁的执行ddl吗？看名字应该是ddl相关的表。

可以判断 是语句查询没有索引造成

这么多啊…

ddl都是半夜执行

image1306×259 29.9 KB

image910×708 56 KB

这是个内存表，走不了索引也走不了tiflash，一直这么跑着消耗集群资源

image617×151 4.33 KB

tidb节点的内存使用率怎么样？

后面的结束时间是什么时间？

将这系统变量关闭，然后重启tidb节点试试。 有位大佬是用这种方式解决的。
set global tidb_enable_auto_analyze_priority_queue=off;

93a6f02f321cad381a986d368320318e668×297 28.1 KB

image677×243 11.4 KB

这个在升级的时候发现bug，已经关了。
auto_nalayze 和ddl 有关系？

猜测这个语句是在analyze这个表的时候产生的。

那就不对了，auto_analyze我是定时任务，半夜才跑
这个sql是全天都有

可以优先排查网络