MySQL 8.0.12+原子DDL不解决MDL锁堆积，仅保障DDL全成功或全失败；它通过事务化元数据更新提升崩溃安全性，但锁获取仍在语句开始前，仍会阻塞并报“Waiting for table metadata lock”。
MySQL 8.0.12+ 的原子 DDL 特性本身不解决 MDL 锁堆积，它只保证 DDL 操作的“全成功或全失败”，但加锁逻辑和阻塞行为依然存在。 换句话说，ALTER TABLE 还是会卡在 Waiting for table metadata lock，只是失败时不会留下半截表或损坏字典项。
为什么原子 DDL 不等于无锁 DDL
原子 DDL 是指 MySQL 将 DDL 操作（如创建索引、添加列）的元数据更新、存储引擎层变更、binlog 写入等步骤封装为一个不可分割的事务单元。它的核心价值在于崩溃安全与数据字典一致性，而非并发控制优化。
MDL 锁的获取时机仍在语句开始前：哪怕你用的是 ALGORITHM=INSTANT 或 ALGORITHM=INPLACE，只要目标表上有未提交的长事务（比如一个没 COMMIT 的 SELECT ... FOR UPDATE），ALTER TABLE 就仍需等待 MDL-X 锁，且后续所有新连接对该表的访问都会被排队阻塞。
- 原子性 ≠ 并发性：DDL 成功/失败可回滚，但锁等待过程不可跳过
- 即使
INSTANT添加列（不拷数据），也需先获取MDL-X，否则无法安全修改mysql.innodb_table_stats等系统表 - 错误信息仍是
ERROR 1105 (HY000): Waiting for table metadata lock，不是新错误类型
如何用原子 DDL 配合其他手段缓解 MDL 堆积
原子 DDL 要真正起作用，必须搭配锁等待控制和前置检查。否则只是“更安全地卡住”。
- 设置超时：在执行 DDL 前显式设低超时，避免无限等待
SET lock_wait_timeout = 10;
再执行ALTER TABLE，超时后报错退出，不长期占连接 - 确认无长事务：查
information_schema.INNODB_TRX中TIME_TO_SEC(NOW() - trx_started) > 60的事务，人工干预或通知业务方 - 避开隐式事务陷阱：ORM（如 Django、MyBatis）常默认开启 autocommit=false，一个简单
SELECT可能开启事务却不COMMIT，这类连接最容易被忽略 - 优先用
ALGORITHM=INSTANT：仅限添加列、重命名列、更改列默认值等极少数操作，它跳过拷表阶段，锁持有时间最短
哪些 DDL 操作实际受益于原子性 + INSTANT
只有满足 INSTANT 条件的 DDL 才能显著缩短锁持有窗口，从而降低堆积概率。不是所有“原子 DDL”都快。
- ✅ 安全使用
ALGORITHM=INSTANT：ADD COLUMN（末尾）、ALTER COLUMN SET DEFAULT、RENAME COLUMN - ❌ 不支持 INSTANT：
DROP COLUMN、MODIFY COLUMN（改类型）、ADD INDEX（仍需INPLACE或COPY） - ⚠️ 注意限制：表不能有全文索引、虚拟列、生成列；且必须是 InnoDB 引擎；MySQL 版本 ≥ 8.0.12
- 验证方式：
SHOW CREATE TABLE t1;查看建表语句中是否含ALGORITHM=INSTANT字样（执行后自动记录）
真正容易被忽略的是：原子 DDL 的“原子”只体现在崩溃恢复层面，对线上业务请求的阻塞毫不存在豁免权。哪怕你用了 INSTANT，只要前面有个没提交的 SELECT，后面一百个连接照样排队等锁——这不是功能缺陷，而是设计取舍：一致性优先于吞吐。处理它，得靠监控长事务 + 控制超时 + 选对算法，而不是指望“原子”二字自动解围。
