大表 DDL：千万级表加字段的正确姿势

加个字段，全站报错

产品要在订单表加一个 remark 字段，老王看表才 4000 万行，随手一条 ALTER TABLE——三秒后接口全线超时报警。这一课学费贵，这篇把大表 DDL 的坑位和正规姿势一次讲透。

先懂堵车：MDL 元数据锁

DDL 动表结构，必须拿到这张表的 MDL 写锁；查询和 DML 拿 MDL 读锁，读写互斥。规则只有两条，但组合起来很要命：

• MDL 写锁申请要排队等所有读锁释放；
• 写锁等待期间，新来的读锁也排在它后面——后面所有查询全部堵死。

于是一个未提交的长事务（哪怕只是 SELECT）持着读锁不放，你的 ALTER 排队，全表的业务查询跟着一起排队——雪崩。排查方法第 15 篇的 metadata_locks 就是为此准备的。做 DDL 前先确认没有长事务，是第一军规。

Online DDL：数据库自带的温和方案

5.6 起 InnoDB 支持在线 DDL，DDL 期间读写大多不被阻塞（短暂的锁只在开始和结束的瞬间）。每种操作的支持度不同，用 ALGORITHM 显式声明并让数据库拒绝不支持的写法：

# INSTANT：只改元数据，秒级完成（8.0.12+ 加列的主力）
ALTER TABLE orders ADD COLUMN remark VARCHAR(255) DEFAULT NULL, ALGORITHM=INSTANT;

# INPLACE：引擎内重建，不复制整表到服务层，期间可读写（耗时但不断流）
ALTER TABLE orders ADD INDEX idx_amount (amount), ALGORITHM=INPLACE, LOCK=NONE;

等级：INSTANT（秒改元数据）> INPLACE（引擎内原地重建）> COPY（建影子表全量复制，锁写）。8.0 的加列默认 INSTANT，这是 8.0 值得升级的实在理由之一；但修改列类型、加全文索引等仍要走 INPLACE 甚至 COPY。INPLACE 重建大表依然要数小时、占双倍空间、产生大量 redo——不断流不等于没成本，主从延迟（第 12 篇）会被 DDL 结束时的大事务补课拉爆。

gh-ost：可控割接的外科手术

更大的表（亿级）、或对限速有要求时，用 gh-ost 这类工具，原理三步：

• 建影子表：按目标结构建 orders_ghost，空表；
• 拷数据 + 追增量：分批把原表数据拷进影子表，同时订阅 binlog 把期间的增删改持续回放到影子表（顺序、限速都可控）；
• 原子割接：数据追平后 RENAME TABLE 原子换名，业务无感。

对比 Online DDL，gh-ost 付出的是双倍存储与更长的总耗时，换来的是可暂停、可限速、可观测、随时中止——生产环境大表变更的安心丸。pt-online-schema-change 同理（用触发器追增量，gh-ost 用 binlog，后者对业务更无侵入）。

大表 DDL 作业清单

• 先查长事务：information_schema.innodb_trx 清场；
• 低峰期执行，明确 ALGORITHM，让不支持的语句直接报错而不是偷偷 COPY；
• 亿级表或需限速：gh-ost，变更前演练与预估时长；
• 主从架构下关注从库回放延迟，必要时逐台执行；
• 能不加字段就不加：扩展表、JSON 字段（低频访问的附属信息）是缓兵之计，但别当万能药。

表结构动得了，数据量继续涨怎么办？分库分表的临界点判断和拆分姿势，下一篇讲。

咖啡凉了，记得趁热喝。