DDL在解析阶段即隐式提交事务，导致此前DML已落库、ROLLBACK无效；这是MySQL明确设计行为，非bug，且不受AUTOCOMMIT=0或BEGIN控制，所有元数据变更类语句均触发该机制。
DDL执行后无法回滚，不是出错了，是MySQL在语句解析那一刻就已提交事务——你看到错误或成功提示时，前面的DML早就落库了。
DDL在解析阶段就隐式提交，不是执行完才提交
很多人以为ALTER TABLE执行失败（比如字段不存在），那前面INSERT还能回滚。错。MySQL在**语法解析完成、真正执行前**，就强制COMMIT当前事务。这意味着：
- 即使
ALTER TABLE t DROP COLUMN nonexistent_col报ERROR 1091，INSERT INTO t VALUES (1)也早已写入磁盘 -
SELECT @@in_transaction在DDL语句执行前返回1，执行后立刻变0 - 存储过程里用
PREPARE+EXECUTE动态执行DDL，同样触发该行为，DECLARE EXIT HANDLER捕获不到事务状态变化
哪些语句会悄悄切开事务？不止ALTER TABLE
只要涉及元数据变更或系统级控制，基本都带“免疫”属性——绕过AUTOCOMMIT=0和BEGIN：
- 对象定义类：
CREATE VIEW、DROP PROCEDURE、RENAME TABLE - 维护类：
ANALYZE TABLE、OPTIMIZE TABLE、REPAIR TABLE - 锁控制类：
LOCK TABLES、UNLOCK TABLES - 账户管理类（8.0+）：
CREATE USER、SET PASSWORD、ALTER USER -
TRUNCATE TABLE是DDL，不是DML，别被名字骗了
CREATE TEMPORARY TABLE是唯一例外，它不触发隐式提交，但只对当前会话有效，且不修改持久元数据。
想安全执行DDL，得放弃“事务兜底”幻想
别再写BEGIN; INSERT; ALTER; ROLLBACK;这种逻辑。真实可行的路径只有三条：
- 拆开执行：先确保DDL成功（如
SELECT COUNT(*) FROM INFORMATION_SCHEMA.COLUMNS WHERE ...查字段是否存在），再跑业务DML；失败则人工介入 - 用工具模拟原子性：
pt-online-schema-change通过影子表+触发器同步，失败自动清理，主表DML不受影响 - 结构迁移替代DDL：
CREATE TABLE new_t AS SELECT * FROM old_t;+RENAME TABLE，但需停写或双写保障一致性
MySQL 8.0的“原子DDL”只解决崩溃恢复问题，不是给你用ROLLBACK撤回的——服务重启后InnoDB能自修复单条DDL中途失败的状态，但客户端层面依然不可控。
最容易被忽略的陷阱：静默提交无提示
没有警告，没有日志标记，ROLLBACK也不报错，只是默默失效。你在Navicat里勾选“自动提交”却混入一条ALTER，事务就被切开了；ORM框架默认屏蔽TRUNCATE，正是因为它既快又危险。真正要防的，不是语法错误，而是事务状态在你没察觉时已终结。
