MySQL 8.4在线DDL加速：Instant Add Column的适用边界与回退方案

Instant Add Column的工作原理

MySQL 8.0.12引入了Instant Add Column，8.4版本进一步完善。Instant DDL的核心思路是在表结构元数据中记录列的”逻辑位置”和”物理位置”的映射关系。新增列只修改元数据，不重建表数据文件，执行时间从数小时缩短到毫秒级。

但Instant Add Column有严格的适用条件。以下场景不支持Instant，会退回Inplace或Copy算法：

1. 新增列添加到表的中间位置（AFTER子句指定非末尾列），只支持添加到末尾
2. 修改已有列的数据类型
3. 表上存在全文索引
4. 使用了ROW_FORMAT=COMPRESSED的表
5. 表含JSON列且版本低于8.0.29
6. 添加自增列（AUTO_INCREMENT）

8.4版本Instant DDL的改进

MySQL 8.4扩展了Instant DDL的支持范围：

Instant Drop Column：8.4支持Instant方式删除列，但只限删除末尾列。中间列的删除仍然需要重建表。实现方式与Add Column对称——元数据中标记列为不可见，物理数据不动，查询时跳过该列。

Instant Modify Column：8.4对部分类型变更支持Instant，比如VARCHAR(50)扩大到VARCHAR(100)，但INT改为BIGINT不行。判断标准是变更前后列的物理存储长度是否变化——不变就可以Instant，变了就不行。

Instant Add Index：这不是传统意义的Instant，而是8.4引入的ALGORITHM=INPLACE加速——在Inplace过程中利用Change Buffer减少锁表时间。本质上还是需要全表扫描构建索引，但锁粒度更细。

判断DDL是否走Instant的实操方法

执行DDL前先用SHOW CREATE TABLE确认表结构，然后运行DDL时加上ALGORITHM=INSTANT子句：

ALTER TABLE orders ADD COLUMN remark VARCHAR(200), ALGORITHM=INSTANT;

如果MySQL支持Instant方式，命令正常执行；不支持则报错ERROR 1845 (HY000): ALGORITHM=INSTANT is not supported for this operation，此时MySQL会告诉你需要用哪种算法替代。这种方式的好处是不会意外触发长时间的Inplace DDL，比不加ALGORITHM子句直接执行更安全。

Instant DDL的隐藏风险

行大小溢出。Instant Add Column不重建表，新增列的值在物理行中是NULL。当后续写入数据时，行大小可能超过innodb_page_size限制（默认16KB对应的行最大约8126字节）。如果表已经有很多VARCHAR列，新增列后写入数据可能触发Row size too large错误。预防方法：执行前用以下查询估算当前最大行大小：

SELECT TABLE_NAME, ROW_FORMAT, AVG_ROW_LENGTH
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'orders';

元数据版本膨胀。每次Instant DDL操作都在元数据中新增一条版本记录。如果一张表反复做Instant DDL（比如自动化Schema Migration脚本反复执行），元数据体积会持续增长，影响表打开速度。8.4提供了ALTER TABLE ... ENGINE=InnoDB来压缩元数据，但这本质上是一次全表重建，只在维护窗口执行。

大表DDL的安全执行流程

对于不能走Instant的大表DDL，推荐流程：

1. 在从库上先执行，观察复制延迟和慢查询情况
2. 确认无异常后，在主库上使用pt-online-schema-change或gh-ost执行
3. 执行过程中监控innodb_buffer_pool_pages_dirty增长率，如果脏页积压过快需要暂停
4. DDL完成后执行ANALYZE TABLE更新统计信息，避免执行计划偏移