MySQL 8.0的ALGORITHM=INSTANT能毫秒级加字段，前提是满足InnoDB表、非COMPRESSED行格式、无全文索引等限制；不满足时会静默降级为INPLACE或COPY，导致锁表超时。
MySQL 8.0 的 ALGORITHM=INSTANT 能彻底解决大表加字段导致的业务超时问题，但前提是操作符合限制条件；不满足时 MySQL 会自动降级为 INPLACE 或 COPY，反而更慢、更卡。
为什么加字段会超时？根本不是“慢”，而是锁表时间太长
在 MySQL 5.7 或 8.0 不支持 INSTANT 的场景下，ADD COLUMN 默认走 INPLACE（重建聚簇索引）或 COPY（全表拷贝），整个过程需逐行读写、重建二级索引、重放 binlog —— 表越大，耗时越长，且期间 DML 被阻塞或大幅延迟。一个 5000 万行的订单表加字段，很容易卡住 20 分钟以上，直接触发应用层连接超时或熔断。
而 INSTANT 的核心是「只改元数据」：不触碰任何一行数据，仅在 INFORMATION_SCHEMA.INNODB_TABLES 和表字典中记录新列定义，执行耗时稳定在毫秒级，DML 完全不受影响。
- 必须是
InnoDB表（MyISAM/Memory不支持） - 不能是
COMPRESSED行格式（ROW_FORMAT=COMPRESSED） - 表不能含全文索引（
FULLTEXTindex） - 不能在同一条语句里混用其他 DDL 操作（如
ADD COLUMN+ADD INDEX） - 新增列不能是主键、唯一约束、自增列，也不能是生成列（
GENERATED）
如何确认当前加字段是否真的走了 INSTANT？
别信“没报错就成功了”。MySQL 在不满足 INSTANT 条件时会静默降级，你看到 Query OK，实际可能跑了十几分钟。
执行完 ALTER TABLE ... ADD COLUMN ... 后，立刻查：
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')
ORDER BY pos;
如果新增列的 has_default = 1 且 default_value 非空（或为 NULL），说明它被标记为 instant 列；再查表级元数据：
SELECT instant_cols FROM INFORMATION_SCHEMA.INNODB_TABLES WHERE name = 'your_db/your_table';
返回值大于 0 才代表本次加列确实用了 instant。若为 0，说明降级了 —— 此时要回溯检查是否误用了 COMPRESSED 行格式、是否带了全文索引等。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
ALGORITHM=INSTANT 必须显式指定吗？
不是必须，但强烈建议。MySQL 8.0.12+ 默认对兼容操作自动选 INSTANT，但这个“自动”依赖准确的元数据判断，某些边缘 case（比如刚从 5.7 升级上来的表、或早期版本创建的含隐藏列的表）可能误判。
显式指定能提前暴露问题：
-
ALTER TABLE t1 ADD COLUMN remark VARCHAR(200) DEFAULT '', ALGORITHM=INSTANT;→ 成功即真 instant -
ERROR 1845 (0A000): ALGORITHM=INSTANT is not supported for this operation.→ 立刻停手，查限制项
注意：8.0.29+ 支持在任意位置加列（AFTER xxx），但 ALGORITHM=INSTANT 仍只允许加在末尾；若指定 AFTER 且位置非末尾，会直接报错，不会降级。
超过 1024 列后加字段 crash 怎么办？
这是真实线上事故高发点：MySQL 8.0.20221221 及更早内核版本，在表已有 1024+ 列时执行 INSTANT ADD COLUMN，可能因行头结构溢出导致 mysqld crash。该 bug 已在 8.0.20241005 版本修复。
如果你的实例尚未升级到该版本：
- 先运行
SELECT REPLACE(name,'/','.') AS 'table_schema.table_name' FROM INFORMATION_SCHEMA.INNODB_TABLES WHERE INSTANT_COLS != 0;找出已存在 instant 列的表 - 对这些表执行
ALTER TABLE xxx ENGINE=InnoDB;（或用pt-osc避免锁表）强制重建，清除潜在损坏的 instant 元数据 - 升级至 8.0.20241005 或更高版本后再加新列
别跳过重建步骤 —— 即使当前没 crash，rollback 时也可能失败，最终导致主从不一致或无法启动。
