MySQL事务中执行ALTER TABLE会立即提交当前事务，因DDL语句触发隐式提交，导致此前DML可回滚而后续操作属新事务，且autocommit设置无效。
MySQL 事务里执行 ALTER TABLE 会立刻提交当前事务
MySQL 在事务中执行任何 DDL（如 ALTER TABLE、DROP INDEX、CREATE VIEW）时，会触发隐式提交（implicit commit），即自动提交当前事务，且无法回滚。这不是 bug，是 MySQL 的明确行为设计。
常见错误现象：ROLLBACK 后发现表结构已经改了，或者事务里前后的 INSERT 一部分生效、一部分没生效——因为 DDL 把事务“劈开”了。
- 所有 DDL 语句在 MySQL 中都属于“非事务性操作”，哪怕引擎是 InnoDB
-
START TRANSACTION或BEGIN之后的首个 DDL，会先提交已有变更，再执行 DDL，再开启新事务（自动） - DDL 前后插入的数据：前面的 INSERT 可回滚，后面的 INSERT 属于新事务，不受之前
ROLLBACK影响
哪些语句会触发隐式提交？不只是 ALTER TABLE
除了显眼的 DDL，很多看似“只读”或“管理类”的语句也会导致隐式提交，容易被忽略。
- 所有 DDL：
CREATE/DROP/ALTER/RENAME表、索引、视图、存储过程等 - 部分管理语句：
ANALYZE TABLE、OPTIMIZE TABLE、REPAIR TABLE - 显式锁控制：
LOCK TABLES和UNLOCK TABLES（注意：SELECT ... FOR UPDATE不在此列） - MySQL 8.0+：
SET DEFAULT ROLE、SET PASSWORD等账户管理语句
关键点：只要语句出现在事务块中，且属于上述类别，就一定会中断事务流。不是“可能”，是“必定”。
如何安全地在业务逻辑中变更表结构？
不能靠事务兜底，就得换思路：把 DDL 拆出业务事务，用外部协调 + 幂等校验来保障一致性。
- 避免在应用层事务中混写 DDL；把结构变更作为独立部署步骤，在服务停写或低峰期执行
- 如果必须动态执行（如 SaaS 多租户场景），先用
SHOW CREATE TABLE检查目标结构是否存在，再决定是否执行ALTER TABLE - 对关键业务表，优先使用在线 DDL 工具（如
pt-online-schema-change），它通过影子表+触发器模拟原子性，但本身仍不进事务 - 日志和监控要覆盖 DDL 执行前后：记录
@@autocommit状态、SELECT @@in_transaction结果，方便追溯异常
autocommit=0 也不能阻止 DDL 的隐式提交
有人以为关掉自动提交就能让 DDL 进事务，其实完全无效。MySQL 会在执行 DDL 前强制提交当前事务，不管 autocommit 是 0 还是 1。
验证方式很简单：
SET autocommit = 0; START TRANSACTION; INSERT INTO t1 VALUES (1); ALTER TABLE t1 ADD COLUMN c2 INT; -- 此刻 INSERT 已提交 ROLLBACK; -- 无效果：c2 字段存在，且 1 这条数据也在
这个机制底层和 MySQL 的元数据锁（MDL）实现强相关——DDL 需要排他 MDL，而事务中的共享 MDL 会冲突，所以必须先清空事务上下文。
真正容易被忽略的是：这种隐式提交不报错、不警告，也没有日志标记（除非打开 general_log），线上出问题时很难归因。
