在 MySQL 中，DDL 语句被定义为非事务性操作，服务器在解析这类语句时就会隐式提交当前事务，因此此前执行的 DML 语句会先行落库且无法回滚；它的“原子性”只体现在崩溃恢复层面，并不支持放入显式事务中统一提交或回滚。

DDL语句在MySQL中被设计为非事务性操作

在 MySQL 数据库里，像CREATE、DROP、ALTER TABLE、TRUNCATE TABLE这类语句，都属于表结构或元数据变更操作。它们不会走 InnoDB 的常规事务日志路径，而是直接修改表定义、刷新到文件系统，并配合元数据锁完成结构变更。这意味着，即使底层使用的是 InnoDB 存储引擎，DDL 语句本身也不受事务管理器统一调度，因为它从设计上就不进入普通事务流程。

隐式提交发生在语句解析阶段，不是执行完成时

很多人误以为“DDL 执行结束后才会提交事务”，但实际上，MySQL 在**解析到 DDL 语句的瞬间**就会强制提交当前事务。也就是说，即便后续 DDL 执行失败（例如ALTER TABLE t DROP COLUMN nonexistent_col报错），前面已经执行的INSERT、UPDATE等 DML 操作也早已提交到数据库，无法再通过回滚撤销。

• SELECT @@in_transaction在执行 DDL 前返回 1，执行后会立即变为 0
• information_schema.INNODB_TRX中对应线程的事务记录会直接消失
• SET autocommit = 0或BEGIN对此类隐式提交行为完全不起作用

哪些语句会触发隐式提交，容易被忽略

会导致 MySQL 隐式提交的并不只有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不改变应用层事务行为

MySQL 8.0 引入的原子 DDL 日志（mysql.innodb_ddl_log）主要用于数据库崩溃恢复，目的是保证单条 DDL 在异常重启后能够恢复到一致且完整的状态。但这套机制并不会对客户端开放事务控制能力：

• ALTER TABLE ... ALGORITHM=INSTANT依然会打断当前事务
• DROP DATABASE、TRUNCATE TABLE等大多数 DDL 语句仍然会强制提交
• 即使在存储过程中执行 DDL，使用START TRANSACTION进行包裹也同样无效

真正需要警惕的不是 DDL 报错本身，而是 MySQL 的静默提交行为——事务在中途被切开，却往往没有明显提示或警告。在业务代码中混用 DDL 和 DML 时，必须通过提前检查INFORMATION_SCHEMA、拆分变更步骤或单独部署结构调整来规避风险，而不能寄希望于最后使用ROLLBACK兜底。