显式指定 ALGORITHM=INSTANT 是刚需，因 MySQL 隐式模式下失败会静默降级为耗时 INPLACE 且不报错；需验证表结构、索引、行格式及版本限制，并通过 information_schema 确认是否真正生效。
MySQL 8.0 的 INSTANT 加列不是默认“开箱即用”的加速功能，而是依赖一整套隐式条件自动触发的机制；不显式指定 ALGORITHM=INSTANT，就等于把判断权交给 MySQL —— 它可能秒完成，也可能静默降级成锁表几分钟的 INPLACE，你根本不会收到任何提示。
为什么显式写 ALGORITHM=INSTANT 是刚需
MySQL 默认行为是“先尝试 INSTANT，失败就自动 fallback”，但这个 fallback 不报错、不告警、不记录日志级别变化。你看到 Query OK，实际执行的可能是耗时数分钟的 INPLACE，而监控里磁盘 IO 突增、主从延迟飙升已经发生。
- 显式指定后，不满足条件会立刻报错：
ERROR 1845 (0A000): ALGORITHM=INSTANT is not supported for this operation，错误信息直接指向问题根因 - 避免在业务高峰期误触降级：比如你本以为加的是末尾字段，但表用了
ROW_FORMAT=COMPRESSED，或存在FULLTEXT索引，隐式模式下完全无法察觉 - 云环境（如 TDSQL-C）中，还需确认
innodb_alter_table_default_algorithm参数值是否为instant，否则即使语句写了也会被参数覆盖
如何快速验证表是否支持 INSTANT 加列
不能只看版本号或执行时间短——小表走 COPY 也可能很快。必须结合结构和元数据交叉验证：
- 查引擎和行格式：
SHOW CREATE TABLE your_table确认是InnoDB且不含ROW_FORMAT=COMPRESSED；再查真实格式：SELECT ROW_FORMAT FROM INFORMATION_SCHEMA.INNODB_TABLES WHERE NAME = 'your_db/your_table'（注意库名小写+斜杠） - 查索引类型：
SHOW INDEX FROM your_table，确保没有FULLTEXT或SPATIAL索引 - 查主键情况：若 MySQL 版本在 8.0.12–8.0.27 区间，需确认表有显式
PRIMARY KEY或至少一个NOT NULL UNIQUE列，否则隐式主键会阻断INSTANT - 查是否压缩表：
SELECT TABLE_NAME, CREATE_OPTIONS FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'your_table'，留意输出中是否含KEY_BLOCK_SIZE
INSTANT 加列后如何确认它真生效了
执行完 ALTER TABLE ... ALGORITHM=INSTANT 后，不能靠“快”来判断，必须查系统表元数据：
- 立即运行：
SELECT table_id, name, pos, has_default, default_value FROM information_schema.innodb_columns WHERE table_id = (SELECT table_id FROM information_schema.innodb_tables WHERE name = 'your_db/your_table') AND name = 'your_new_column' - 若返回结果中
has_default = 1且default_value字段非空（或为NULL），说明是INSTANT添加；若查不到该行，说明未走INSTANT（可能失败，也可能降级） - 额外验证：
SELECT instant_cols FROM INFORMATION_SCHEMA.INNODB_TABLES WHERE name = 'your_db/your_table'，返回值应为正整数（表示当前已使用的 instant 版本数），且不超过 64
容易被忽略的硬性限制与版本差异
很多“明明是 8.0 却不生效”的问题，都卡在这些细节上：
-
DEFAULT值只能是字面量（DEFAULT 0、DEFAULT 'abc'），不能是函数（NOW()、UUID()）、表达式或子查询；DEFAULT NULL是允许的，但NULL本身不写DEFAULT就不算 - 8.0.12–8.0.28 不支持
AFTER col_name或FIRST，哪怕显式指定也会静默 fallback；只有 8.0.29+ 才真正支持任意位置加列 - 每张表最多支持 64 次
INSTANT增删列操作（TOTAL_ROW_VERSIONS），超限后所有后续INSTANT操作都会失败，必须重建表重置计数器 - 新增列不能是
PRIMARY KEY、AUTO_INCREMENT、STORED GENERATED列；VIRTUAL生成列可以，但不常用
INSTANT 的本质是元数据变更，不是数据搬运——它快得理所当然，但也脆弱得不容试错。最危险的不是它不工作，而是你以为它在工作，其实早已悄悄降级。每次加列前，花 30 秒查一遍 INFORMATION_SCHEMA，比等业务报警后再回滚要便宜得多。
