Instant DDL 表结构限制怎么配置或排查

MySQL 的 Instant DDL 不是一个可以“一键打开”的全局开关。对 InnoDB 来说，正确做法是把目标操作写清楚：适合即时变更时显式使用 ALGORITHM=INSTANT，让服务器不满足条件时直接报错；不要让它悄悄退回更重的算法。MySQL 8.4 中，Instant 是默认算法，但表结构和操作类型仍然决定能否成功。

一、先确认 DDL 类型与算法边界

先把多个修改拆开，避免一个不支持 Instant 的动作拖累整条语句。下面这条语句只新增一列，并要求服务器严格按即时算法处理：

-- 只验证新增列是否满足 Instant，失败时不要自动降级
ALTER TABLE orders
  ADD COLUMN source_channel VARCHAR(32) NULL DEFAULT NULL,
  ALGORITHM=INSTANT;

-- 改默认值通常只改元数据，仍建议显式写出算法
ALTER TABLE orders
  ALTER COLUMN source_channel SET DEFAULT 'web',
  ALGORITHM=INSTANT;

在 MySQL 8.4 中，Instant 加列可以放在任意位置，但不能和不支持 Instant 的其他 ALTER 动作混在同一条语句里。改列类型、调整列顺序、增加普通二级索引等操作，不能因为“也是 ALTER TABLE”就推断为 Instant。显式算法的价值是把判断交给服务器：成功就是元数据级变更，失败则立即暴露边界。

二、检查表结构和 Instant 元数据

遇到“为什么我的表不能 Instant”，先查事实，不要先调参数。压缩行格式、带 FULLTEXT 索引的表、数据字典表空间中的表和临时表，都可能排除某些 Instant 列操作。用下面的查询把表的关键特征一次列出来：

-- 先看存储引擎、行格式和表空间归属
SELECT TABLE_SCHEMA, TABLE_NAME, ENGINE, ROW_FORMAT, TABLESPACE_NAME
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = 'shop'
  AND TABLE_NAME = 'orders';

-- 再看全文索引；存在 FULLTEXT 时不要按普通 InnoDB 表判断
SELECT INDEX_NAME, INDEX_TYPE, NON_UNIQUE
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = 'shop'
  AND TABLE_NAME = 'orders'
  AND INDEX_TYPE = 'FULLTEXT';

-- 查看 Instant 加删列累计的 row version
SELECT NAME, ROW_FORMAT, SPACE_TYPE, TOTAL_ROW_VERSIONS
FROM INFORMATION_SCHEMA.INNODB_TABLES
WHERE NAME = 'shop/orders';

TOTAL_ROW_VERSIONS 初始为 0，每次用 Instant 加列或删列都会增加；MySQL 8.4 的上限是 64。达到上限时，继续 Instant 加删列会失败，解决办法不是把某个变量调大，而是用会重建表的 ALTER TABLE 或 OPTIMIZE TABLE 清掉历史 row version。查询 INNODB_TABLES 需要相应的 PROCESS 权限。

三、按限制选择配置与替代方案

只有“即时列变更”适合直接用 ALGORITHM=INSTANT。如果需要创建索引、改变数据类型或重排列，通常要评估 INPLACE 或 COPY，并明确锁级别。在线重建期间并发写入过多，才可能受到在线变更日志上限影响：

-- 只读查看在线重建日志上限，单位是字节
SHOW VARIABLES LIKE 'innodb_online_alter_log_max_size';

-- 需要在线重建时，明确算法和锁级别；先在影子表评估耗时
ALTER TABLE orders
  ADD INDEX idx_channel_created (source_channel, created_at),
  ALGORITHM=INPLACE,
  LOCK=NONE;

innodb_online_alter_log_max_size 的默认值在 MySQL 8.4 文档中为 134217728 字节，控制 InnoDB 在线 DDL 临时日志的上限。它解决的是“在线重建时并发 DML 日志过大”的问题，不会解除 Instant 加删列的 row version 上限，也不能让不支持 Instant 的操作变成 Instant。生产环境应先确认磁盘余量、锁等待和变更窗口，再决定是否调整。

四、上线前做小表验证和回滚准备

建议建立一张与生产表保持同样 row format、全文索引和表空间特征的影子表，先执行带显式算法的语句。验证结果至少记录三件事：语句实际采用的算法、是否出现 metadata lock 等待、执行前后的 TOTAL_ROW_VERSIONS。如果只是达到 64 次限制，安排一次可控重建后再恢复 Instant 变更；如果是表结构不兼容，就改走 Inplace 或维护窗口中的 Copy。

常见问题

MySQL 8.4 还需要写 ALGORITHM=INSTANT 吗？

默认算法是 Instant，但显式写出可以防止操作在不满足条件时采用更重路径，也便于把失败原因留在变更记录中。

为什么加列很多次后突然不能 Instant？

Instant 加列和删列会累积 row version；MySQL 8.4 上限为 64。用会重建表的 ALTER 或 OPTIMIZE TABLE 归零后再安排后续变更。

调大在线 DDL 日志能解决这个限制吗？

不能。该变量只约束在线重建期间记录并发 DML 的临时日志；它与 Instant 的表结构限制是两条不同的排查路径。