能，但仅当严格满足六条件：单add column、末尾添加、字面量默认值、innodb引擎、dynamic/compressed行格式、无fulltext索引；任一不满足即退化为inplace或copy，耗时从毫秒升至小时级。
INSTANT算法在MySQL 8.0中真的能秒加列吗？
能，但只限于特定场景——ADD COLUMN且新列允许为NULL（或有默认值但不触发重写）、不指定AFTER位置、表引擎为InnoDB、且表未使用COMPRESSED行格式。一旦条件不满足，MySQL会自动降级为INPLACE甚至COPY，耗时从毫秒跳到小时级。
为什么ALTER TABLE ... ADD COLUMN有时还是卡住？
常见触发降级的原因有：
-
ADD COLUMN name VARCHAR(255) NOT NULL：NOT NULL且无DEFAULT→ 必须填充全表，强制COPY -
ADD COLUMN ... AFTER xxx：指定位置会破坏INSTANT的元数据-only机制 → 降级为INPLACE - 表存在
FULLTEXT索引或SPATIAL索引 → INSTANT不支持 - MySQL 8.0.12之前版本或启用了
innodb_file_format=Antelope→ INSTANT不可用 -
ALTER TABLE t1 ALGORITHM=INSTANT显式指定但条件不满足 → 报错ER_ALTER_OPERATION_NOT_SUPPORTED
怎么验证INSTANT是否真正生效？
执行后立刻查INFORMATION_SCHEMA.INNODB_TABLESTATS或用SHOW PROFILE看阶段耗时，更直接的是观察ALTER语句返回时间（通常
- 执行成功后，
SELECT * FROM t1 LIMIT 1能立刻看到新列，值为NULL（若未设DEFAULT） -
SHOW CREATE TABLE t1里新列出现在最后，且无AFTER子句 - 错误日志里没有
Copying to tmp table或Rebuilding the table字样 - 系统变量
innodb_online_alter_log_max_size无需调大（INSTANT不写online log）
生产环境加列前必须检查的三件事
别只盯着语法对不对，重点看运行时状态：
- 确认
SELECT VERSION()≥8.0.12，且innodb_file_format为Barracuda（SHOW VARIABLES LIKE 'innodb_file_format'） - 用
SELECT ROW_FORMAT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME='t1'确保不是COMPRESSED - 执行
SELECT COUNT(*) FROM information_schema.KEY_COLUMN_USAGE WHERE TABLE_NAME='t1' AND COLUMN_NAME='new_col'提前排除同名列冲突（INSTANT不校验列名唯一性，冲突会在插入时报错）
INSTANT的本质是只改数据字典，不碰聚簇索引页，所以它快得“不真实”——但这也意味着新增列在首次写入前不会分配物理空间，某些备份工具或复制延迟监控可能因此漏判结构变更。这点容易被忽略。
