MySQL在事务中执行DDL会立即隐式提交当前事务，导致前面DML已落库、后续ROLLBACK无效；该行为发生在语法解析阶段而非执行完成时，且涵盖CREATE、DROP、ALTER、ANALYZE TABLE等语句，仅CREATE TEMPORARY TABLE例外。
MySQL 多语句事务中一旦执行 DDL，事务立即中断，前面的 DML 已落库，后续 ROLLBACK 完全无效——这不是流程“异常”，而是 MySQL 明确设计的行为。
DDL 语句在解析阶段就强制提交事务
很多人以为 ALTER TABLE 执行完才提交，其实 MySQL 在**语法解析完成、还没真正执行结构变更时**，就已经把当前事务提交了。这意味着：
-
INSERT和UPDATE已写入磁盘，ROLLBACK对它们不起作用 - 即使
ALTER TABLE后面报错（比如字段不存在），前面的 DML 也回不去了 -
SAVEPOINT在 DDL 前设好也没用，DDL 会直接清空整个保存点栈 -
SELECT @@in_transaction在 DDL 执行后立刻返回0，事务上下文彻底丢失
哪些语句会悄无声息地劈开事务
除了常见的 CREATE、DROP、ALTER TABLE，这些语句同样触发隐式提交，却容易被忽略：
- 表维护类：
ANALYZE TABLE、OPTIMIZE TABLE、REPAIR TABLE - 锁控制类：
LOCK TABLES（哪怕只是READ锁）、UNLOCK TABLES - 账户管理类（MySQL 8.0+）：
SET DEFAULT ROLE、SET PASSWORD - 元数据操作：
CREATE VIEW、CREATE PROCEDURE、CREATE TRIGGER
CREATE TEMPORARY TABLE 是唯一例外，它不触发隐式提交，但只对当前会话有效，且不涉及持久元数据。
如何在运行时确认事务是否还“活着”
不能靠肉眼判断 SQL 类型，必须用状态查询验证。关键检查点有三个：
- 执行可疑语句前：
SELECT TRX_ID, TRX_STATE FROM information_schema.INNODB_TRX WHERE TRX_MYSQL_THREAD_ID = CONNECTION_ID();—— 应返回一行且TRX_STATE = 'RUNNING' - 执行后立刻查：
SELECT @@in_transaction;—— 若变成0，说明事务已被切开 - 应用层日志中记录：
conn.get_autocommit()和conn.in_transaction()（PyMySQL / mysql-connector-python 支持）
特别注意：存储过程中动态拼接并执行 PREPARE stmt FROM @sql; EXECUTE stmt;，只要 @sql 是 DDL，一样触发隐式提交。
DDL 必须和业务逻辑联动时怎么办
没有真正的“DDL 进事务”，只有解耦与补偿。常见做法有：
- 用
pt-online-schema-change：通过影子表 + 触发器同步，失败自动清理，原表 DML 不受影响 - 两阶段拆分：先确保
ALTER TABLE成功，再执行业务 DML；DML 失败需人工或脚本补偿（如DROP COLUMN几乎不可逆） -
CREATE TABLE AS SELECT+RENAME TABLE：新建结构表、导入数据、原子切换；但需停写或双写，复杂度高
最危险的不是报错，而是静默提交——事务状态被切开，却没有任何警告。线上变更务必提前验证事务连续性，而不是依赖 ROLLBACK 兜底。
