MySQL中DDL语句执行前即隐式提交当前事务，导致此前DML已落库、ROLLBACK无效；这是官方设计行为，非bug，且SET AUTOCOMMIT=0或BEGIN无法阻止。
因为DDL语句（如CREATE、DROP、ALTER TABLE）会触发MySQL的隐式提交，不是“执行完再提交”，而是在执行前就把当前事务强制提交了——所以ROLLBACK根本没东西可回滚。
DDL执行前就已隐式提交
这不是bug，是MySQL明确设计的行为。只要事务中出现任意DDL语句，MySQL会在真正解析并执行它之前，先对当前未提交的DML（比如INSERT、UPDATE）做一次COMMIT。之后才开始处理DDL本身。这意味着：
-
BEGIN→INSERT→ALTER TABLE→ROLLBACK：INSERT早已落盘，ROLLBACK只作用于一个空事务 - 哪怕
SET autocommit = 0也拦不住，DDL自带“免疫”能力 -
TRUNCATE TABLE同属DDL，同样不可回滚，别被“看起来像DML”骗了
MySQL 5.7和8.0在DDL原子性上的本质区别
很多人误以为“8.0支持DDL回滚”是指能在用户事务里ROLLBACK，其实不是。8.0的“原子DDL”指的是崩溃恢复层面的自保能力，和你写的BEGIN/ROLLBACK无关：
- MySQL 5.7：元数据散落在
.frm、.TRG等文件中，由MyISAM引擎管理，崩溃后可能只剩半截表（DROP TABLE t1, t2只删掉t1） - MySQL 8.0：
mysql.tables等元数据全存InnoDB表里，配合隐藏表mysql.innodb_ddl_log记录物理操作步骤；崩溃重启后InnoDB自动回滚整个DDL事务，但这是服务层行为，不暴露给客户端 - 你仍然不能在
START TRANSACTION里写ALTER TABLE然后靠ROLLBACK撤回——语法上允许，逻辑上无效
想安全地条件执行DDL，得绕过事务机制
既然不能靠事务兜底，就得提前检查、避免报错。比如“字段存在才删”，不能靠IF EXISTS直接写在SQL里（MySQL不支持DDL级的条件语法），必须借助元数据查询：
- 查
INFORMATION_SCHEMA.COLUMNS确认字段是否存在：SELECT COUNT(*) FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 'tbl' AND COLUMN_NAME = 'col' - 结果为1时，再拼接执行
ALTER TABLE tbl DROP COLUMN col（通常用存储过程或应用层控制流实现） - 注意：
ALTER TABLE ... DROP COLUMN IF EXISTS在MySQL 8.0.19+才支持，且仅限DROP COLUMN，ADD COLUMN或MODIFY COLUMN仍无此语法
真正容易被忽略的是：DDL的隐式提交发生在语句解析阶段，不是执行阶段——你看到错误提示（比如字段不存在）时，前面的DML早就提交了。别指望靠异常捕获来补救，得从脚本组织方式上隔离DDL和DML。
