ALGORITHM=INSTANT能毫秒加列，但需同时满足InnoDB引擎、末尾加列、非TEXT/BLOB/JSON/GEOMETRY类型、无DEFAULT表达式、无FULLTEXT索引等全部硬性条件，任一不满足即退化为INPLACE或COPY导致卡住。
ALGORITHM=INSTANT 能实现毫秒级加列，但前提是语句和表结构完全合规——不满足任一条件就会退化为 INPLACE 或 COPY，耗时从毫秒跳到分钟甚至小时。
为什么加个字段还会锁表或卡住？
常见现象是执行 ALTER TABLE t ADD COLUMN x INT 后，SHOW PROCESSLIST 显示状态长期卡在 altering table，或者监控里看到磁盘 IO 突增、主从延迟飙升。这不是 MySQL 坏了，而是 INSTANT 没生效，自动降级了。
根本原因在于：MySQL 8.0 默认会尝试 INSTANT，但只要触发任一硬性限制，就立刻放弃，改走传统流程。它不会报错提醒你“没走 instant”，只会默默变慢。
- 表引擎不是
InnoDB（比如MyISAM、Memory） -
ROW_FORMAT是COMPRESSED或设置了KEY_BLOCK_SIZE - 表上存在
FULLTEXT索引 - 语句里混了其他 DDL，例如
ADD COLUMN a INT, ADD INDEX idx_b(b) - MySQL 8.0.12–8.0.27 版本中，表没有显式主键且无
NOT NULL UNIQUE列（即隐式主键）
如何确认 INSTANT 是否真正生效？
不能只看执行时间短——小表即使走 COPY 也可能很快。最可靠的方式是查元数据是否标记为 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。
更直接的验证方式是观察物理行为：
- 对 1TB 表执行加列，耗时
- 执行期间
SELECT * FROM t LIMIT 1能立刻返回，且新列值为NULL或你指定的默认值 → 符合 instant 的“运行时合成”特征 - 执行前后
SELECT COUNT(*) FROM t耗时几乎不变 → 说明没扫描/重写数据行
带 DEFAULT 值的列还能走 INSTANT 吗？
能，但仅限于 DEFAULT NULL 或省略 DEFAULT（等价于 DEFAULT NULL）。一旦写 DEFAULT 'abc' 或 DEFAULT 42，就必然退化。
原因很底层：instant 的本质是“不往老数据里写值”，只在字典里记下“这个列默认是 X”。但对非 NULL 默认值，MySQL 无法区分“这行本来就没有该列”和“这行该列值就是 X”，语义冲突。所以必须把值真实写入每一行——这就绕不开全表扫描。
安全做法分两步：
- 先用 instant 加空列：
ALTER TABLE t ADD COLUMN c VARCHAR(32) NULL; - 再用批处理更新（配合主键范围分片）：
UPDATE t SET c = 'abc' WHERE id BETWEEN 1 AND 100000;
注意：不要用 UPDATE t SET c = 'abc' 全表扫，否则锁表+日志爆炸。
ALGORITHM=INSTANT 显式指定有用吗？
有用，但作用不是“强制启用”，而是“强制校验”。加上 ALGORITHM=INSTANT 后，如果条件不满足，MySQL 会直接报错：
ERROR 1845 (0A000): ALGORITHM=INSTANT is not supported for this operation
这反而比静默降级更可控——你能立刻知道哪条规则被违反，而不是等到业务报警才发现加列花了 40 分钟。
建议在线上关键操作中始终显式带上：
ALTER TABLE t ADD COLUMN c INT NULL, ALGORITHM=INSTANT;- 不带
ALGORITHM的语句，在 8.0.28+ 版本中可能因内核小版本差异导致行为不一致（比如某些版本允许AFTER，有些直接报错） - 云环境（如 RDS）需主从都开启
loose_innodb_instant_ddl_enabled=ON，否则只读实例复制中断
真正容易被忽略的是：instant 不是“开关”，而是一组严丝合缝的契约。少一个条件，整条链路就断掉——它快得惊人，也脆得真实。
