MySQL中DDL等语句在解析阶段即触发隐式提交，导致当前事务立即结束，此前DML无法回滚；触发语句包括CREATE、DROP、ALTER、TRUNCATE、RENAME、ANALYZE、OPTIMIZE、LOCK TABLES、GRANT等，唯CREATE TEMPORARY TABLE例外。
ALTER TABLE 执行时事务已被切开，不是“回滚失效”，而是事务早已结束——这是 MySQL 的确定行为，不是 bug，也改不了。
哪些语句会触发隐式提交？
只要 MySQL 解析到以下任一类语句，就会立刻提交当前事务（哪怕还没执行完），后续 ROLLBACK 对此前 DML 无效：
-
所有 DDL 操作：
CREATE、DROP、ALTER TABLE、TRUNCATE TABLE、RENAME TABLE、CREATE VIEW、DROP PROCEDURE -
部分维护语句：
ANALYZE TABLE、OPTIMIZE TABLE、REPAIR TABLE -
锁控制语句：
LOCK TABLES、UNLOCK TABLES -
账户管理语句（MySQL 8.0+）：
CREATE USER、ALTER USER、GRANT、REVOKE、SET PASSWORD
CREATE TEMPORARY TABLE 是唯一例外，它不触发隐式提交，但只在当前会话有效，且不修改持久元数据。
为什么不是“执行完才提交”，而是“一解析就提交”？
隐式提交发生在 SQL 解析阶段，不是执行完成时。这意味着：
- 即使
ALTER TABLE t DROP COLUMN nonexistent_col报错，前面的INSERT也早已落库 -
DECLARE EXIT HANDLER在存储过程中捕获异常后调用ROLLBACK，只能回滚 DDL 之后的操作，对 DDL 前的 DML 完全无能为力 -
SELECT @@in_transaction在 DDL 前返回1，执行后立刻变0；information_schema.INNODB_TRX中对应记录直接消失
为什么 SET AUTOCOMMIT=0 或 START TRANSACTION 拦不住？
DDL 被设计为非事务性操作，绕过 InnoDB 事务日志路径，走的是元数据锁 + 文件系统写入 + 强制刷盘流程。事务控制开关对它完全无效：
-
SET AUTOCOMMIT = 0不影响 DDL 行为 -
BEGIN或START TRANSACTION包裹 DDL，只是让 DDL 前的 DML 看起来“在事务里”，但 DDL 一出现，事务就终结 - MySQL 8.0 的原子 DDL 日志（
mysql.innodb_ddl_log）仅用于崩溃恢复，不提供事务边界控制
怎么提前发现代码里混了隐式提交？
不能靠肉眼扫 SQL，得看运行时状态：
- 执行关键语句前查：
SELECT TRX_ID, TRX_STATE FROM information_schema.INNODB_TRX WHERE TRX_MYSQL_THREAD_ID = CONNECTION_ID()，若返回TRX_STATE = 'RUNNING'，说明事务还活着 - 执行疑似 DDL 后立刻查：
SELECT @@in_transaction，值变为0就确认已提交 - 应用层日志中记录
conn.get_autocommit()和conn.in_transaction()（PyMySQL / mysql-connector-python 支持）
最危险的不是报错，是静默提交——事务被切开，却没有任何提示或警告。DDL 和业务 DML 共存于同一上下文（尤其是存储过程或 ORM 迁移脚本）时，必须靠拆分部署步骤来规避，而不是指望 ROLLBACK 兜底。
