TiDB v7.5 大表 ALTER ADD COLUMN 很慢，如何评估是否改用 online DDL？

mike117 · 2026 年7 月 17 日 02:50

【TiDB 使用环境】测试环境
【TiDB 版本】v7.5.6
【部署方式】tiup 物理机，3 PD / 3 TiDB / 5 TiKV
【问题描述】
业务表约 2 亿行，执行 ALTER TABLE ... ADD COLUMN 耗时很长，期间业务偶发报 information schema is changed。
想确认：
1）这种规模更推荐原生 DDL 还是 lightning/同步旁路方案？
2）如何提前评估 DDL 耗时与对 QPS 的影响？
3）有没有推荐的监控项（DDL job / TiKV 写入）在变更前重点看？
请教实战经验，谢谢。

Defined2014 · 2026 年7 月 17 日 02:53

add column 的耗时和表大小无关，TiDB 的 ddl 都是 online 的，你这个大概率是有别的 sql 阻塞了 DDL 进程，可以找到 sql kill 掉或者重启一下每个 TiDB

克里克里克 · 2026 年7 月 17 日 03:24

这个应该是后台日志报的吧，应用层面应该是没感知的，或者响应会慢。如果担心有影响可以考虑调低参数：tidb_ddl_reorg_worker_cnt和tidb_ddl_reorg_batch_size。
DDL耗时与QPS的影响官方有过压测，可以找一下，DDL的最佳实践；
变更前的评估项应该没有，只有执行后看看集群的Duration，如果感觉有影响可以暂时pause，低峰执行。

TiDBer_bawpguhQ · 2026 年7 月 17 日 05:43

2 亿行 DDL 选 online schema change：先 ADD COLUMN DEFAULT NULL（秒级不填数据），再分批 backfill。预估耗时看 INFORMATION_SCHEMA.DDL_JOBS 的 row_count 和增量写入速率。监控 TiKV coprocessor 的 DDL consume 防止挤占在线。

TiDBer_AHjy0eKV · 2026 年7 月 18 日 02:05

等半夜再操作?

yg_2024 · 2026 年7 月 21 日 01:35

1、推荐业务低峰期直接DDL操作，大表加空字段执行时间大概5~15分钟的样子，“information schema is changed”一般是只出现在DDL的最后阶段，这个是必然发生，但是量很小时间也比较短基本上秒级（毕竟TiDB做DDL变更不需要抢锁，不阻塞DML）。
2、评估耗时的话，只能是找个同规模的集群有同等大小的表测下。但是对业务的影响，就只能在生产中积累经验了，前期可以观察下小表，渐进增加生产变更的范围。
3、加字段，基本上就是关注DDL JOB运行情况，主要还是观察集群的整体负载。

独善其身 · 2026 年7 月 21 日 01:36

开启 Online DDL 后，ALTER TABLE ADD COLUMN 自动走异步后台任务：

不持有全局 Schema 锁，业务正常读写，不会报 IS 变更；
元信息变更瞬间完成，后台异步处理数据回填（有 DEFAULT/not null 场景）；
支持暂停、取消、观察进度，可错峰执行；
对 QPS 冲击平缓，后台限速不打垮 TiKV。

daodao0101 · 2026 年7 月 21 日 08:18

建议测试环境先压一把。2亿行原生DDL在v7.5默认走回填，耗时跟TiKV写入能力强相关，可以先用ALTER TABLE … ADD COLUMN … ALGORITHM=INSTANT（仅限末尾加列）试试。如果必须中间加列，推荐用pt-osc或gh-ost做online DDL，对QPS影响更可控。

个人测试 · 2026 年7 月 21 日 10:39

应该可以吧？

daodao0101 · 2026 年7 月 23 日 02:33

应该可以吗

Soysauce520 · 2026 年7 月 23 日 07:20

有没有加默认值？

徐大大爱学习 · 2026 年7 月 24 日 03:31

解决了吗

TiDBer_lbHbY6at · 2026 年7 月 25 日 08:27

推荐优先使用原生 DDL ，TiDB 的 DDL 操作是在线异步变更的，执行期间不会阻塞正常的读写操作，耗时很长通常有其他原因，而不是 DDL 本身的设计缺陷。你的问题应该是别的事务导致的，查看进度：使用 ADMIN SHOW DDL JOBS;

TiDBer_AHjy0eKV · 2026 年7 月 25 日 10:06

等没人时候再做

健康的腰间盘 · 2026 年8 月 4 日 00:59

有办法了吗，同样的问题

Loving · 2026 年8 月 5 日 07:00

建议低峰时操作，正常都会或多或少的影响，想完全不影响似乎不可能。

daodao0101 · 2026 年8 月 5 日 11:36

推荐优先使用原生 DDL ，TiDB 的 DDL 操作是在线异步变更的，执行期间不会阻塞正常的读写操作，耗时很长通常有其他原因，而不是 DDL 本身的设计缺陷。你的问题应该是别的事务导致的，查看进度：使用 ADMIN SHOW DDL JOBS;

a大力啊 · 2026 年8 月 7 日 02:08

虚心学习

Lucien-卢西恩 · 2026 年8 月 7 日 02:31

ADD COLUMN 官方说明

v7.5.6 默认开启 Metadata Lock。DDL 长时间不结束，更应该先检查是否被旧事务阻塞。如果增加字段后还要给 2 亿行历史数据赋业务值，建议拆成两个步骤：

先执行原生 ADD COLUMN。
再由应用按主键范围小批量回填，控制每批事务大小和并发。

这时真正需要评估的是后续 DML 回填速度和 TiKV 写入压力，而不是用旁路工具替代 ADD COLUMN。

daodao0101 · 2026 年8 月 7 日 02:54

v7.5.6 默认开启 Metadata Lock。DDL 长时间不结束，更应该先检查是否被旧事务阻塞。如果增加字段后还要给 2 亿行历史数据赋业务值，建议拆成两个步骤：

先执行原生 ADD COLUMN。
再由应用按主键范围小批量回填，控制每批事务大小和并发。

这时真正需要评估的是后续 DML 回填速度和 TiKV 写入压力，而不是用旁路工具替代 ADD COLUMN