MySQL 5.7 不支持 INSTANT 算法，仅支持 COPY 和 INPLACE；INSTANT 是 MySQL 8.0.12 引入的，仅修改元数据、不重写行数据，执行 ADD COLUMN 等操作时秒级完成。
MySQL 5.7 不支持 INSTANT 算法，别被版本混淆误导
INSTANT 算法是 MySQL 8.0.12 引入的，5.7 完全不识别 ALGORITHM=INSTANT。如果你在 5.7 执行 ALTER TABLE t ADD COLUMN c INT, ALGORITHM=INSTANT，会直接报错 ERROR 1845 (0A000): ALGORITHM=INSTANT is not supported。官方文档明确将 INSTANT 列为 “8.0.12+ only”，5.7 最多只支持 INPLACE 和 COPY。
INSTANT 为什么快？只改元数据，不碰行数据
INSTANT 的核心是跳过行格式变更和数据重写，仅在数据字典（SDI）里追加字段定义，并用 row version 标记每行数据是否“见过”这个新字段：
- 新增列（
ADD COLUMN）且不设NOT NULL DEFAULT时，老数据行不补值，读取时按默认值或NULL填充 - 删除列（
DROP COLUMN）从 8.0.29 起才支持 INSTANT，靠的是行版本比对：若行版本 - 字段重命名（
CHANGE COLUMN）不触发 INSTANT，哪怕语义等价，因为涉及列定义哈希变更
哪些操作看似简单，但 INSTANT 实际不支持？
INSTANT 表面轻量，实则限制极严。以下操作即使只改长度或类型，也会 fallback 到 INPLACE 或 COPY：
-
ALTER TABLE t MODIFY COLUMN name VARCHAR(256)：从VARCHAR(255)扩容到256，长度字节数从 1 字节升为 2 字节，必须重建行结构 → 触发COPY -
ALTER TABLE t ALTER COLUMN c SET DEFAULT 'x'：修改默认值本身不改行存储，但 8.0.33 前该语法强制走INPLACE；8.0.33+ 才允许 INSTANT（需满足无NOT NULL约束等条件） -
ALTER TABLE t DROP PRIMARY KEY：任何主键变更都要求重建聚集索引 → 只能COPY - 含全文索引、空间索引、生成列的表，INSTANT 支持度大幅下降，多数 DDL 会退化
线上执行前必须确认的三件事
INSTANT 不是银弹，尤其在线上大表场景，容易因隐式降级引发长锁或空间爆满：
- 查版本：
SELECT VERSION()，确保 ≥ 8.0.12；再确认innodb_default_row_format是DYNAMIC（COMPACT格式下 INSTANT 支持有限） - 看执行计划：
EXPLAIN FORMAT=TRADITIONAL ALTER TABLE t ADD COLUMN x INT，输出中若出现alter_algorithm: copy或inplace: 0，说明 INSTANT 已失效 - 盯临时空间：
INPLACE仍需innodb_online_alter_log_max_size日志缓冲，而COPY会写#sql-ib*.ibd中间文件——如果磁盘剩余
真正危险的不是 INSTANT 本身，而是你以为它在生效，结果后台悄悄切成了 COPY，锁表两小时才发现。
