mysql ddl 语句会自动提交当前事务且无法回滚，包括create、drop、alter、truncate等，即使在显式事务中执行也会触发隐式提交，导致后续rollback失效。
MySQL DDL 语句会自动提交当前事务，无法回滚
只要在事务中执行了 CREATE、DROP、ALTER、TRUNCATE 等 DDL 语句，MySQL 会立刻隐式提交（implicit commit）当前事务，之后的 ROLLBACK 完全失效。这不是 bug，是官方明确行为——DDL 在 MySQL 中被设计为“非事务性操作”，即使引擎支持事务（如 InnoDB），DDL 本身也不参与事务控制。
常见错误现象：
– 手动 BEGIN 后插入几条数据，再 ALTER TABLE 加个字段，最后 ROLLBACK，结果发现插入的数据还在；
– 在存储过程中用 START TRANSACTION 包裹 DDL 和 DML，误以为能原子执行。
- 所有 DDL 都触发隐式提交，包括
RENAME TABLE、ANALYZE TABLE、OPTIMIZE TABLE -
CREATE TEMPORARY TABLE是唯一例外，它不触发提交，但仅限于临时表 - DDL 前若存在未提交的修改，会在 DDL 执行前被强制提交，不是“丢弃”而是“立刻落盘”
如何判断某条语句是否触发隐式提交
最直接的方式是查 MySQL 官方文档的「Statements That Cause an Implicit Commit」章节，但日常开发中更实用的是记住高频触发点：
- 任何修改表结构、索引、视图、存储过程/函数、触发器、事件的语句都会触发
-
LOCK TABLES和UNLOCK TABLES也会（哪怕只是READ锁） -
SET AUTOCOMMIT = 1切换自动提交模式时，会立即提交当前事务 -
START TRANSACTION或BEGIN本身不会提交，但它的前置未提交操作会被“清空”——即如果之前有未提交的 DML，执行BEGIN会先隐式提交它们（注意：这是 MySQL 5.7+ 行为，5.6 及以前不这样）
一个快速验证方法：在客户端执行 SELECT @@autocommit;，确认是 1；然后 BEGIN → INSERT → SELECT 看到新数据 → ALTER TABLE ... → 再 ROLLBACK → SELECT 仍能看到刚才的 INSERT，就说明已提交。
想让 DDL 和 DML 原子执行？没有原生方案，只能绕开
MySQL 不支持把 DDL 当作事务语句来处理，所以不存在“把 ALTER 和 UPDATE 放进同一个事务并一起回滚”的语法。实际项目中遇到这类需求，得靠应用层协调：
- 拆成两阶段：先做 DDL（确保成功），再做 DML；失败则人工或脚本回退 DDL（比如
DROP COLUMN回退难，但ADD COLUMN可逆） - 用
pt-online-schema-change这类工具做 DDL，它本身不阻塞写入，且自带失败回滚逻辑（回滚的是临时表和触发器，不是原表事务） - 业务上接受“最终一致性”：比如加字段后，代码兼容新旧结构，等所有写流量切过去再清理旧逻辑
- 避免在事务块里混写 DDL —— 这是最容易被忽视的编码习惯问题，尤其 ORM 自动生成 schema 时（如 Django 的
migrate、Laravel 的php artisan migrate）默认不在事务里跑 DDL，但开发者手动写DB::transaction()包裹迁移就可能踩坑
autocommit=0 时 DDL 的行为差异
很多人以为关掉自动提交就能“控制 DDL”，其实不然。即使 SET autocommit = 0，DDL 依然强制提交——它根本不受 autocommit 开关影响。
关键区别在于 DML：
-
autocommit = 1：每个 DML 单独成事务，DDL 执行前会先提交上一条 DML -
autocommit = 0：DML 累积到显式COMMIT，但一旦遇到 DDL，所有累积的 DML 立刻提交，DDL 自己也单独提交
示例：SET autocommit = 0;INSERT INTO t VALUES (1);ALTER TABLE t ADD c INT;ROLLBACK;
执行完 ALTER 后，INSERT 已落地，ROLLBACK 对它无效。
真正容易被忽略的点是：DDL 的隐式提交不可禁用、不可延迟、不可捕获。它像系统级中断，发生即生效，连 SAVEPOINT 都拦不住。写自动化部署脚本或数据库迁移工具时，必须把它当作独立的、不可逆的操作单元来设计流程。
