DDL语句在MySQL中被设计为非事务性操作，解析时即隐式提交当前事务，导致此前DML已落库且不可回滚；其原子性仅限崩溃恢复，不支持嵌入显式事务。
DDL语句在MySQL中被设计为非事务性操作
MySQL把CREATE、DROP、ALTER TABLE、TRUNCATE TABLE这类语句归为元数据变更操作，它们不走InnoDB的事务日志路径，而是直接修改表结构定义、刷盘文件系统、加元数据锁。这意味着：即使你用的是InnoDB引擎，DDL本身也不受事务管理器调度——它压根不进事务流程。
隐式提交发生在语句解析阶段，不是执行完成时
很多人以为“DDL执行完才提交”，实际是MySQL在**解析到DDL语句那一刻**就强制提交当前事务。哪怕后续执行失败（比如ALTER TABLE t DROP COLUMN nonexistent_col报错），前面的INSERT或UPDATE早已落库。
-
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兜底。
