TiDB 集群频繁出现 DDL 执行超时，新增表结构变更全部卡住故障

[个人练习生 (Ti D Ber O Lb6d0s K)]

线上 TiDB 集群日常增删改查业务正常无延迟，运维发起新增索引、新增字段等 DDL 语句时，任务长时间无进展并最终超时失败，多张表的 DDL 任务全部阻塞，TiKV、PD 资源负载均处于低位。

[wbslxw (Ti D Ber Cl S0j Eng)]

排查并终止长时间未提交的事务，释放元锁，解除 DDL 阻塞队列
调高集群 DDL 并行调度的线程数量，支持多表结构变更同时推进
检查全部 TiDB 实例运行状态，异常节点重启后同步完整元数据
适当拉长 DDL 全局超时等待时长，避免短时阻塞就直接失败
运维操作错开业务高峰，拆分大批量、多表 DDL 分批次执行，减少并发拥堵

[克里克里克 (Ti D Ber H052ej9m)]

列出使用版本，确认是否bug。

[随缘天空 (Ti D Ber Ivw R7o Pj)]

在tidb节点的服务器上执行如下命令试试，tikv和pd服务器不需要执行：
mkdir /tmp/tidb/tmp_ddl-4000 -p
chown tidb:tidb -R /tmp/tidb

[BI小z (Ti D Ber U Nrr6xc O)]

检查 DDL Owner 节点状态、是否存在长事务 / 元数据锁，重启 DDL Owner 或重新选举，排查 DDL 队列阻塞。

[狂拽瘸子好腿 (Ti D Ber 8u Uk Olqy)]

你这个 DDL 全部超时阻塞但业务读写正常的问题，大概率是被长事务 / 长会话阻塞了。TiDB 执行 Online DDL 时需要获取表的元数据锁，如果有长时间未提交的事务、或持有元数据锁的会话，会导致 DDL 任务排队等待锁，最终超时失败。建议先通过 ADMIN SHOW DDL JOBS 查看 DDL 任务状态，再用 SHOW PROCESSLIST 和 SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST 排查长会话，同时用 SELECT * FROM INFORMATION_SCHEMA.TIDB_TRX WHERE TIME > 60 找出超过 60 秒未提交的长事务，将其主动 kill 掉后 DDL 通常就能恢复；另外可以检查 tidb_ddl_reorg_worker_cnt、tidb_ddl_reorg_batch_size 等参数是否配置过小，或是否开启了非默认的 DDL 模式，也可以临时调大 ddl-timeout 超时时间，配合分批执行、业务低峰期执行 DDL 来规避锁竞争。

[kang]

用explain analyze看是否走了正确索引。

[TiDBer_bgWIGhji]

热点本质是PD调度算法和负载模式不匹配。