如何避免MySQL隐式提交破坏事务一致性

DDL语句一定会破坏当前事务，无例外；ALTER TABLE、DROP TABLE、CREATE INDEX、TRUNCATE TABLE、LOCK/UNLOCK TABLES、SET AUTOCOMMIT=1、START TRANSACTION、ANALYZE/OPTIMIZE TABLE及所有存储过程定义语句均触发隐式提交，导致此前DML已落库且ROLLBACK无效。

DDL 语句一定会破坏当前事务，没有例外，也不存在“把它包进事务就能回滚”的做法。

哪些 SQL 会触发隐式提交

只要执行了以下任一语句，MySQL 就会立即提交当前事务（哪怕你刚 BEGIN 还没做任何 DML）：

1. ALTER TABLE、DROP TABLE、CREATE INDEX、TRUNCATE TABLE
2. LOCK TABLES 和 UNLOCK TABLES
3. SET AUTOCOMMIT = 1（注意：设为 0 不触发，设为 1 才触发）
4. START TRANSACTION（它本身会先隐式提交前一个事务）
5. LOAD DATA INFILE、ANALYZE TABLE、OPTIMIZE TABLE
6. 所有存储过程/函数定义类语句：CREATE PROCEDURE、ALTER FUNCTION 等

常见错误现象：在 Navicat 中勾选“自动提交”，又粘贴了一段含 ALTER TABLE 的脚本——结果前几条 INSERT 已落地，ROLLBACK 完全无效。

如何提前发现事务已被切开

不能靠“我写了 BEGIN 就一定还在事务里”这种假设。运行时必须验证：

1. 执行疑似 DDL 前，查 SELECT @@in_transaction，值为 1 才说明事务活跃
2. 更可靠的是查 SELECT TRX_ID, TRX_STATE FROM information_schema.INNODB_TRX WHERE TRX_MYSQL_THREAD_ID = CONNECTION_ID()，若返回空行或 TRX_STATE != 'RUNNING'，事务已不在
3. 应用层（如 Python + PyMySQL）可在关键点打日志：conn.get_autocommit() 和 conn.in_transaction 要一起看，单看一个容易误判

DDL 必须和业务逻辑一起执行怎么办

接受它不可回滚的事实，再设计补偿路径，而不是硬塞进事务：

1. 用 pt-online-schema-change 替代直接 ALTER TABLE：它不锁主表，失败自动清理，DML 不中断，适合线上大表
2. 拆成两阶段：先单独执行 ALTER TABLE 并确认成功；再开启新事务跑业务 DML；若 DML 失败，需人工或脚本补偿（比如新增字段可删，但删字段几乎无法回退）
3. 用 CREATE TABLE AS SELECT + RENAME TABLE：建新表、导数据、原子切换。但期间需停写或双写，复杂度高，仅适用于低流量时段

真正容易被忽略的点是：很多 ORM 或迁移工具（如 Django migrate、Laravel migrate）底层会动态拼接 ALTER TABLE 并 EXECUTE，它们同样触发隐式提交——你看到“事务回滚”日志，其实只是回滚了 DDL 之后的操作。