MySQL INSTANT ADD COLUMN 怎样判断 DDL 是否支持

给生产表新增一列时，真正需要先回答的不是“语句能不能执行”，而是“它会不会悄悄走更重的算法”。在 MySQL 8.4 中，InnoDB 的普通 ADD COLUMN 默认优先使用 ALGORITHM=INSTANT，但特殊表属性、组合变更、行大小和生成列仍可能让它不成立。

最稳妥的写法是把算法写进 DDL：ALGORITHM=INSTANT 支持就执行，不支持就明确失败，再根据错误决定是否改用 INPLACE 或 COPY。官方资料地址：https://dev.mysql.com/doc/refman/8.4/en/innodb-online-ddl-operations.html

判断 INSTANT 是否支持，不要只看“新增列”这四个字。先显式指定算法，再把表属性、列定义和组合动作拆开检查；这样失败会发生在发布窗口之前，而不是变成一次不可预期的重建。

先把算法写死，才能知道它是否真的支持

我在迁移脚本里会先写出最小变更，并显式指定算法。下面的语句不是为了制造一个“必然成功”的例子，而是让数据库在不满足条件时给出确定的拒绝信号。

-- 用显式算法让不支持的变更直接失败，避免静默走重算法。
ALTER TABLE orders
  ADD COLUMN source_code VARCHAR(32) NULL,
  ALGORITHM=INSTANT,
  LOCK=NONE;

这里的 source_code 是普通可空列，语句只表达一个新增动作。ALGORITHM=INSTANT 让迁移目标变得可审查；LOCK=NONE 则把并发写入的期望写出来。两者不是“强制成功开关”：若操作不支持，MySQL 会报错，发布脚本应该停止并记录原因。

普通 ADD COLUMN 支持，不等于所有新增列都支持

判断时可以先把“操作本身”和“表的现实条件”分开。普通 InnoDB 表新增列通常只改元数据，并允许并发 DML；但同一条 ALTER TABLE 如果还混入不支持 INSTANT 的动作，整条语句就不能按 INSTANT 完成。

例如，新增列与调整列顺序、修改数据类型、增加需要重建表的约束放在同一条语句中，就不应再把它当作一个轻量新增列。迁移脚本最好一条只做一个目的，先把可瞬时的动作单独提交。

哪些情况会让 INSTANT 直接失败

官方限制里最容易被忽略的是：使用 ROW_FORMAT=COMPRESSED 的表、带 FULLTEXT 索引的表、数据字典表空间中的表以及临时表，可能不能用 INSTANT 新增列。MySQL 还会检查新增后的最大行大小，超过上限时会拒绝。

生成列也要单独看：新增 VIRTUAL 生成列与新增 STORED 生成列不是同一件事。后者需要计算表达式并重建表，不能沿用普通列新增的判断。

ALTER TABLE orders
  ADD COLUMN total_amount DECIMAL(12,2)
    GENERATED ALWAYS AS (unit_price * quantity) STORED,
  ALGORITHM=INSTANT;

-- STORED 生成列需要重建表时，先确认维护窗口再选择回退算法。
ALTER TABLE orders
  ADD COLUMN total_amount DECIMAL(12,2)
    GENERATED ALWAYS AS (unit_price * quantity) STORED,
  ALGORITHM=COPY;

如果第一条失败，不要只删掉算法参数重跑。省略算法可能让 MySQL 按可用能力选择其他路径，迁移风险反而更难被看见。

把失败原因变成上线前清单

在真正执行前，至少完成四个动作：确认表是 InnoDB；查看表是否使用压缩行格式、是否包含 FULLTEXT 索引或属于临时表；把复杂 ALTER 拆成单一动作；最后在与生产相同的版本和表结构上显式尝试 INSTANT。

如果报错指向最大可能行大小，就先评估列类型、长度和现有列数量；如果是特殊表属性或生成列限制，则应选择有维护窗口的 INPLACE 或 COPY，并预估锁、空间与回滚方案。回退算法不是“更保险的默认值”，而是明确知道代价后才使用的迁移决策。

-- 先读取表定义，确认迁移前提；不要把 SHOW 输出当成线上执行结果。
SHOW CREATE TABLE orders;

-- 用显式算法做兼容性演练；失败时保留错误文本供发布系统分流。
ALTER TABLE orders
  ADD COLUMN source_code VARCHAR(32) NULL,
  ALGORITHM=INSTANT,
  LOCK=NONE;

相关问题

省略 ALGORITHM 会怎样？

MySQL 会在可用算法中选择路径。对迁移审查来说，显式写出目标算法更容易发现不支持场景，也更方便发布系统按错误中止。

INSTANT 失败后应该直接改成 COPY 吗？

不应该直接改。先判断失败是表属性、行大小、组合动作还是生成列造成的，再决定拆分、使用 INPLACE，或在维护窗口执行 COPY。

这个方法能证明线上一定不锁表吗？

不能。它只把算法和锁定意图写清楚；实际影响仍取决于操作类型、表结构、版本和并发负载，不能把静态说明图当成运行证据。