MySQL 8.0前ALTER TABLE会隐式提交事务，导致ROLLBACK失效；8.0起部分DDL支持原子性但受限于算法（如INSTANT），DROP DATABASE等仍强制提交；安全做法是DDL与DML物理隔离。
MySQL 8.0 之前在事务里执行 ALTER TABLE 会自动提交
不是报错，而是悄悄提交当前事务——这是最危险的地方。你写了个 BEGIN，中间夹了条 ALTER TABLE，后面再 ROLLBACK，发现前面的 INSERT 或 UPDATE 全没回滚，因为事务早被 DDL 强制结束了。
原因很简单：MySQL 5.7 及更早版本不支持 DDL 的原子性，所有 DDL（CREATE、DROP、ALTER、RENAME）都会触发隐式提交（implicit commit），哪怕你没写 COMMIT。
- 哪怕事务里只有
SELECT+ALTER TABLE，ALTER执行完，事务状态就变成“已提交” -
SHOW VARIABLES LIKE 'autocommit'设为OFF也拦不住——DDL 不吃这套 - 如果你依赖事务边界做数据一致性校验（比如先改配置表再改主表），这个隐式提交会让校验完全失效
错误现象：为什么 ROLLBACK 像没发生一样
典型表现是：执行完 ALTER TABLE 后，再执行 ROLLBACK，命令成功返回，但之前做的 DML 没回滚。这不是 bug，是设计如此。
你可以用 SELECT @@in_transaction 验证：在 ALTER 前它是 1，执行后立刻变 0；或者查 information_schema.INNODB_TRX，事务记录已经消失。
- 错误日志里不会报错，也不会警告，安静得可怕
- 应用层如果没检查事务状态，可能误以为整个逻辑块还在一个事务里
- ORM（如 Django、SQLAlchemy）若自动生成 DDL（比如迁移脚本），更容易踩中这个坑
MySQL 8.0+ 的变化：DDL 支持原子性，但仍有条件
8.0 引入了原子 DDL 日志（mysql.innodb_ddl_log），让部分 DDL 真正支持事务语义——但仅限于满足条件的操作。
关键限制是：ALTER TABLE 必须是 “instant” 或 “inplace” 算法，且不能涉及存储引擎重建（比如从 MyISAM 转 InnoDB）、不能加全文索引、不能修改主键列类型等。一旦触发 copy table，仍会隐式提交。
- 用
SHOW CREATE TABLE查当前表结构，再对比你要执行的ALTER是否属于 instant 操作（如加列、删列、改列默认值） - 执行前加
ALGORITHM=INSTANT显式指定，失败时会报错而不是退化成 copy table - 即使 8.0，
DROP DATABASE、TRUNCATE TABLE依然强制提交，不享受原子 DDL
安全做法：把 DDL 和 DML 彻底拆开
别指望在同一个事务里混用 DDL 和业务逻辑。最稳妥的方式就是物理隔离——先完成所有 DDL，再开启新事务跑 DML。
如果必须按顺序执行（比如加字段 → 写默认值 → 更新旧数据），就在应用层控制流程，每步之间重新连接或显式 COMMIT / BEGIN，并检查返回状态。
- 运维脚本里，用
mysql -e "ALTER ..."单独执行 DDL，再调用另一个脚本跑业务 SQL - 应用代码中，避免 ORM 的 auto-migrate 在事务上下文中触发；迁移应作为部署前置步骤单独运行
- 监控层面，可抓取慢查询日志里的
ALTER，配合COMMIT时间戳，识别出是否出现在事务块内
DDL 的事务行为从来就不是“能不能”，而是“在哪一版、对哪类操作、以什么方式能”。想靠一个开关统一控制，容易漏掉引擎层、算法选择、版本差异这些硬约束。
