订单表加字段时一直停在 waiting for table metadata lock，是表太大还是有人开着长事务？

直接给订单表加字段会不会卡住线上写入，答案不取决于表看起来有多少行，而取决于这一次是只改数据字典，还是要整表重建，以及执行那一刻旁边有没有长事务。按 2026 年常见交付经验，字段加在末尾、类型简单、条件满足只改元数据时，多数在毫秒到秒级完成；一旦落到整表重建，几百万行的表跑十几分钟到一两个小时都落在常见区间。而真正让接口整体超时的，往往不是重建本身慢，是元数据锁排队把后面所有请求一起堵死了。

一、报 waiting for table metadata lock，先分清是改表慢还是被堵住

改表语句要拿到这张表的排他元数据锁才能开始。执行那一刻，如果有长事务、未提交的查询或者长时间空闲的连接还持有旧表定义，alter 就得排队；排队期间，后面新到的普通查询又会排在 alter 后面，于是这张表上的读写一起变慢，表现出来像整站卡住。值班时看到的通常是接口超时告警，真正的起点却是别处一个没提交的事务。

所以看到这条提示，先别去调大锁等待超时，那个参数只决定等多久放弃，不改变排队这个事实。先打开会话列表按执行时间排一遍，看有没有长事务、有没有 sleep 很久的空闲连接、有没有正在跑的报表或备份任务，清掉之后再决定什么时候执行。这一步花的时间，通常比把变更挪到凌晨更值。

• 重建表本身吃 IO：同实例的其他业务会跟着变慢，受影响的不只是这一张表。
• 锁等待会外溢：一个长事务卡住，后面所有访问这张表的请求都堆在队列里。
• 从库回放更慢：主库一次性跑完，从库要串行回放，延迟会被拉长。
• 磁盘水位：重建期间新旧两份数据并存，临时空间要提前留够。

这几项里，锁等待外溢是最需要防的一项，其余三项只是变慢。变慢可以等，队列堵住就只能靠提前清场来避免。

二、这次加字段是改元数据还是要重建，怎么判断

数据库官方文档里有在线 DDL 的支持矩阵，但它给的是能力边界，不是这一次的具体代价。落到项目上，我们习惯按加列前四看过一遍：前三项决定会不会重建，第四项决定重建会不会演变成事故。

1. 看算法：能不能走只改元数据那条路径，受版本、行格式、是否压缩表等条件限制，条件不满足就退回重建。
2. 看列的位置与类型：加在末尾、允许 NULL 或有默认值的普通列，代价小；加在中间列、改类型、改字符集，基本都是重建。
3. 看表规格：行数、单行平均长度和二级索引数量共同决定耗时，索引越多，搬数据越慢。
4. 看流量与长事务：有没有报表连接和批处理在跑，当前写入量能不能扛住这段时间的抖动。

第四条最容易被跳过。不少线上事故不是改表慢，是改表撞上了没清掉的长事务，前者只是慢，后者会放大成全站排队。所以执行前五分钟清会话，优先级高于挑时间。

预发按同量级数据实测，比盯着文档猜靠谱

把生产表结构克隆到预发，导入相近量级的数据跑一次，看实际耗时和磁盘增量，是常见也划算的做法。数据量差一个数量级，耗时可能差好几倍，但只要实测出现从秒级跳到分钟级，就说明这一次不是改元数据，后面的安排要按重建来做。

三、三条路径的成本与周期，按经验区间对比

确认要重建之后，通常有三条路：直接 alter、在线改表工具、影子表加双写。三者不是新旧替代关系，而是按表规模和能接受的中断风险分层，方向选错比参数调错更费时间。

• 直接 alter：几十万行以内、条件合适时，常见在秒级到几十秒；几百万行触发重建时，常见区间是十几分钟到一两个小时；额外磁盘和额外组件接近零；风险是把锁和延迟直接暴露给业务。
• 在线改表工具：一边拷数据一边追增量，收尾阶段做一次短暂切换；需要额外磁盘，约等于数据加索引的体积再留余量，还要求表上有可用主键或唯一键；几百万到千万行，常见区间是几十分钟到数小时；风险落在切换那一两秒的短暂锁，以及工具被中断后残留的触发器和中间表。
• 影子表加双写：应用层同时写新旧表，比对校验后再切读；周期常见按天到按周算，适合超大表或一致性要求较高的场景；代价是要改代码、要写比对脚本，还得能容忍一段时间的双份写入。

选择标准可以压成一句：能接受几十秒以内的写入抖动就走直接 alter，接受不了就走工具，连工具切换那一下也不能接受，才值得上双写。反过来，几万行的配置表为加一个字段搭一整套双写，属于过度设计，维护成本比省下来的风险更高。

四、交付现场：窗口四小时、表三百万行、还挂着夜间报表

2026 年上半年一个项目里遇到的情况比较典型：甲方只给四小时窗口，订单表三百万行上下，挂着每晚跑的报表查询，预算里没有另采买运维平台。约束是时间紧、没人全程盯、又尽量不停业务，做法是提前在预发按同量级数据实测一次，执行前用会话列表清掉长事务和长时间空闲连接，临时停掉当晚报表任务，从库先改、主库后改，工具拷贝速度做限流以免挤占在线写入。结果是重建比预发实测多跑了将近一倍，切换那一两秒出现少量写入重试，报表第二天补跑了一次。

这类表的耗时，常见区间是直接 alter 十几分钟到一小时多，在线工具四十分钟到三小时，具体取决于索引数量和实例规格。代价不算大，但如果当晚没清会话，大概率会从慢一点变成整段时间接口超时，那就不是补跑一次报表能收场的了。类似变更，犀跃公司在交付时会把预发实测数据和会话清理清单写进变更单，不靠临场判断。

五、什么时候值得先评估，什么时候不必

需要走完整评估流程的，是中大型业务表、有持续写入、还有报表或批处理共用同一实例的情况；这类表即使这一次侥幸秒级完成，也值得把流程固化下来，因为下一次未必这么顺。

• 不必上工具：几万行以内的配置表、日志归档表，或者本来就有可停机窗口的内部系统。
• 可以直接改：字段加在末尾、条件满足只改元数据，且执行前后能确认没有长事务。
• 不建议硬上：主从延迟本来就高、磁盘余量不足，或者执行时段根本没人盯着。

六、改完怎么验收，几个常被忽略的坑

加字段本身不复杂，出问题的多半在周边环节。验收口径建议固定为四项：结构比对一致、行数与关键字段校验和一致、从库延迟回到基线、业务写入成功率恢复，四项都对上再算完成，只看其中一项很容易漏掉后遗症。

• 只改了主库，忘了另一个环境上的同结构表，代码取字段时报不存在。
• 磁盘余量按表数据大小估，忽略了索引和临时文件，跑到一半空间不足。
• 工具中途被中断，触发器和中间表没清干净，后续写入出现重复。
• 新列默认值与代码判空逻辑不一致，历史行读出来是 NULL 而不是预期值。
• 顺手把字符集一起改了，本来只改元数据，变成整表转换，耗时翻倍。

常见问题

加个字段就几秒钟的事，为什么还要专门评估？

因为耗时由实现算法决定，不由字段个数决定。一旦落到重建表，几百万行跑几十分钟到一两个小时都在常见区间，评估是为了提前知道这次落在哪一档。

放在凌晨低峰期执行，是不是就不用管了？

低峰只降低影响面，不改变锁和延迟的性质。低峰期同样可能有备份、批处理和报表长事务，执行前仍要清一遍会话。

用了在线改表工具，是不是就没什么风险了？

工具只是把锁的持续时间压短，仍需额外磁盘、可用主键和足够的日志保留；切换瞬间的短暂锁、中断后的清理，都要提前安排。

从库要不要一起改，会不会把主从延迟拉得很难看？

要改，通常先改从库再切主库。DDL 在从库是串行回放的，大表重建会把延迟拉长，切换前要确认延迟已回到基线。

表结构改完之后，怎么算这次变更合格？

结构比对一致、行数与关键字段校验和一致、从库延迟回到基线、业务写入成功率恢复，四项都对上再收工。

如果你手上正好有一张要加字段的表，先做两件事：在预发按同量级数据跑一次实测，把执行前要清理的长事务和空闲连接列成清单。几十万行以内、条件合适时直接改通常够用；到千万级又对写入中断敏感时，再考虑在线工具或双写，不必为了省一次评估把整段业务写进去。