MySQL中DDL语句被设计为非事务性操作，执行时立即隐式提交当前事务，导致此前DML无法回滚；其原子性仅指单条DDL自身崩溃安全，不支持嵌入显式事务。
DDL语句在MySQL中被设计为非事务性操作
MySQL把CREATE、DROP、ALTER TABLE、TRUNCATE TABLE等DDL语句归类为“元数据变更操作”，它们直接修改表结构、索引定义或数据库对象，不走InnoDB的事务日志路径，而是触发独立的元数据锁 + 文件系统写入 + 强制刷盘流程。这意味着：即使引擎支持ACID，DDL本身也不参与事务管理器调度。
隐式提交发生在语句解析阶段，不是执行完成时
很多人误以为“DDL执行完才提交”，实际上MySQL在**解析到DDL语句那一刻**就强制提交当前事务——哪怕后续执行报错（比如ALTER TABLE t DROP COLUMN nonexistent_col），前面的INSERT或UPDATE也早已落库。这导致异常捕获（如存储过程里的DECLARE EXIT HANDLER）完全无法回滚已提交的DML。
-
SELECT @@in_transaction在DDL前返回1，执行后立刻变0 -
information_schema.INNODB_TRX中对应线程的记录消失 -
SET autocommit = 0或BEGIN对它完全无效
哪些语句会触发隐式提交，容易被忽略
不只是ALTER TABLE，以下语句同样会劈开事务：
- 所有对象定义类：
CREATE VIEW、DROP PROCEDURE、RENAME TABLE - 维护类：
ANALYZE TABLE、OPTIMIZE TABLE、REPAIR TABLE - 锁控制类：
LOCK TABLES、UNLOCK TABLES - 账户管理类（MySQL 8.0+）：
SET DEFAULT ROLE、SET PASSWORD
CREATE TEMPORARY TABLE是唯一例外，它不触发隐式提交，但只作用于当前会话且不涉及持久元数据。
MySQL 8.0的原子DDL不改变应用层事务行为
8.0引入的原子DDL日志（mysql.innodb_ddl_log）仅用于崩溃恢复层面，确保单条DDL在服务异常重启后能自恢复完整状态。但它不暴露给客户端事务控制：
-
ALTER TABLE ... ALGORITHM=INSTANT仍会中断当前事务 -
DROP DATABASE、TRUNCATE TABLE等绝大多数DDL依旧强制提交 - 存储过程中执行DDL，
START TRANSACTION包裹无效
真正危险的不是报错，而是静默提交——事务状态被切开，却没有任何提示或警告。业务逻辑里混用DDL和DML时，必须靠提前查INFORMATION_SCHEMA或拆分部署步骤来规避，而不是指望ROLLBACK兜底。
