MySQL 8.0.12+ 的 INSTANT 算法仅在满足全部条件时生效：ADD COLUMN、加在末尾、DEFAULT 为字面量、ROW_FORMAT 为 Dynamic/Compact、非生成列/全文索引列等，否则自动降级为 INPLACE 或 COPY。
能不锁表，但前提是你得看清版本、算法和字段定义——MySQL 8.0.12+ 用 ALGORITHM=INSTANT 才真“秒加”；低于这个版本，ALGORITHM=INPLACE, LOCK=NONE 是底线，否则大概率卡住业务。
MySQL 8.0.12+ 怎么触发 INSTANT 算法？
INSTANT 不是默认开启的，它只在满足全部条件时才生效。漏掉任意一条，MySQL 就自动降级为 INPLACE（可能重建表）甚至 COPY（全锁表）。
- 必须是
ADD COLUMN，且加在表末尾（即没用AFTER xxx指定中间位置） - 不能带
DEFAULT表达式，比如DEFAULT CURRENT_TIMESTAMP或DEFAULT (uuid())—— 只允许字面量，如DEFAULT 'N'或DEFAULT 0 - 表不能启用
ROW_FORMAT=COMPRESSED或KEY_BLOCK_SIZE > 0 - 不能是
GENERATED列、全文索引列、空间列 - 执行前建议先查下是否满足：运行
SELECT * FROM information_schema.INNODB_TABLES WHERE NAME LIKE '%your_table%';，确认ROW_FORMAT是Dynamic或Compact
验证是否真的 INSTANT：执行完 ALTER TABLE t ADD COLUMN c1 INT 后，查 performance_schema.events_statements_history，看 ALGORITHM 字段是不是 INSTANT；或者观察执行耗时是否稳定在毫秒级。
MySQL 5.7–8.0.11 用 INPLACE 为什么还会卡住？
很多人写了 ALGORITHM=INPLACE, LOCK=NONE 就以为万事大吉，结果 DDL 卡在 Waiting for table metadata lock。这不是算法问题，是元数据锁（MDL）被长事务堵住了。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- DDL 开始和结束两个瞬间，需要短暂获取
MDL_EXCLUSIVE锁；如果此时有未提交的事务（哪怕只是BEGIN; SELECT ...;没COMMIT），DDL 就会排队等待 - 检查阻塞源：
SELECT * FROM performance_schema.threads WHERE PROCESSLIST_COMMAND = 'Sleep' AND PROCESSLIST_TIME > 60;，再关联performance_schema.events_statements_current看它在执行什么 - 线上紧急处理：优先 kill 掉长时间 Sleep 的连接，而不是强行重试 DDL
- 预防手段：应用层避免显式
BEGIN后不提交；DBA 设置wait_timeout和interactive_timeout缩短空闲连接生命周期
千万级表加字段，为什么不能直接 ALTER？
即使走 INPLACE，对大表来说“不锁表”≠“无代价”。重建聚簇索引 + 所有二级索引，IO 和 CPU 压力巨大，可能拖慢从库复制、打满磁盘带宽、触发监控告警。
- 120GB 的订单表，INPLACE ADD COLUMN 可能产生等量写入放大，SSD 寿命和 IOPS 都吃紧
- 从库延迟飙升：主库 DDL 执行期间，从库要重放整个重建过程，不是简单 apply binlog
- 更稳的选择是
gh-ost或pt-online-schema-change：它们用影子表 + 触发器同步增量，把压力拆成小批次，还能暂停/限速 - 注意
gh-ost要求表有唯一/主键，且不能有外键约束（外键会失效）；pt-osc对外键支持稍好，但触发器开销略高
Java 应用层怎么配合加字段？
数据库加了字段，不代表代码能立刻读写。尤其当字段非空且有默认值时，老代码 INSERT 不带该字段，就会报错 Column 'xxx' cannot be null。
- 推荐三阶段上线：
加可空字段 → 应用灰度写入 → 数据补全 → 改 NOT NULL（可选） - MyBatis 中如果用了
<insert></insert>标签且没显式列出字段名，新增字段会被忽略，不会出错但数据为空；建议统一改成INSERT INTO t (col1,col2,...) VALUES (#{v1},#{v2},...)显式声明 - Spring Data JPA 如果用
@Entity+@Column映射，新增字段需同步加字段+getter/setter，否则启动时报Unknown column - 最危险的是“默认值陷阱”：MySQL 定义了
DEFAULT 'pending'，但 JDBC 连接参数里开了useServerPrepStmts=true，某些驱动版本会把默认值当成客户端默认，导致插入时字段值被覆盖
INSTANT 看似轻巧，但它只解决“加字段那一刻”的锁，不解决后续的数据一致性、应用兼容性和从库压力。真正安全的操作，永远是版本判断 + 条件校验 + 分阶段上线 + 监控兜底。
