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）：
-
ALTER TABLE、DROP TABLE、CREATE INDEX、TRUNCATE TABLE -
LOCK TABLES和UNLOCK TABLES -
SET AUTOCOMMIT = 1（注意：设为 0 不触发，设为 1 才触发） -
START TRANSACTION（它本身会先隐式提交前一个事务） -
LOAD DATA INFILE、ANALYZE TABLE、OPTIMIZE TABLE - 所有存储过程/函数定义类语句：
CREATE PROCEDURE、ALTER FUNCTION等
常见错误现象：在 Navicat 中勾选“自动提交”，又粘贴了一段含 ALTER TABLE 的脚本——结果前几条 INSERT 已落地，ROLLBACK 完全无效。
如何提前发现事务已被切开
不能靠“我写了 BEGIN 就一定还在事务里”这种假设。运行时必须验证：
- 执行疑似 DDL 前，查
SELECT @@in_transaction，值为 1 才说明事务活跃 - 更可靠的是查
SELECT TRX_ID, TRX_STATE FROM information_schema.INNODB_TRX WHERE TRX_MYSQL_THREAD_ID = CONNECTION_ID()，若返回空行或TRX_STATE != 'RUNNING'，事务已不在 - 应用层（如 Python + PyMySQL）可在关键点打日志：
conn.get_autocommit()和conn.in_transaction要一起看，单看一个容易误判
DDL 必须和业务逻辑一起执行怎么办
接受它不可回滚的事实，再设计补偿路径，而不是硬塞进事务：
- 用
pt-online-schema-change替代直接ALTER TABLE：它不锁主表，失败自动清理，DML 不中断，适合线上大表 - 拆成两阶段：先单独执行
ALTER TABLE并确认成功；再开启新事务跑业务 DML；若 DML 失败，需人工或脚本补偿（比如新增字段可删，但删字段几乎无法回退） - 用
CREATE TABLE AS SELECT+RENAME TABLE：建新表、导数据、原子切换。但期间需停写或双写，复杂度高，仅适用于低流量时段
真正容易被忽略的点是：很多 ORM 或迁移工具（如 Django migrate、Laravel migrate）底层会动态拼接 ALTER TABLE 并 EXECUTE，它们同样触发隐式提交——你看到“事务回滚”日志，其实只是回滚了 DDL 之后的操作。
