最直接确认事务被隐式提交的方法是执行DDL后查@@in_transaction，若值由1变为0即证实；更稳妥的是DDL前后均查询information_schema.INNODB_TRX，若DDL前TRX_STATE='RUNNING'而DDL后无记录或状态改变，即可断定发生隐式提交。
怎么确认事务被隐式提交了
最直接的办法是执行完疑似 DDL 操作后立刻查 @@in_transaction。如果值从 1 变成 0，说明事务已终结——不是你主动 COMMIT 或 ROLLBACK 的，就是被隐式提交了。
更稳妥的方式是在 DDL 前后都查 information_schema.INNODB_TRX：
- DDL 前执行
SELECT TRX_ID, TRX_STATE FROM information_schema.INNODB_TRX WHERE TRX_MYSQL_THREAD_ID = CONNECTION_ID();，应返回一行且TRX_STATE = 'RUNNING' - DDL 后再执行一次，结果为空或
TRX_STATE不再是RUNNING，基本可断定隐式提交发生 - 注意：MySQL 8.0.22+ 中
@@in_transaction更可靠；5.7 下建议优先依赖INNODB_TRX查询
哪些语句会触发隐式提交
别只盯着 ALTER TABLE，这些操作全都会：
- 所有 DDL：包括
CREATE/DROP/TRUNCATE/RENAME TABLE/ANALYZE TABLE/OPTIMIZE TABLE - 部分管理语句：
LOCK TABLES（哪怕只是READ锁）、UNLOCK TABLES、SET AUTOCOMMIT = 1 -
CREATE TEMPORARY TABLE是唯一例外，它不触发隐式提交 - 存储过程中动态执行的
PREPARE+EXECUTE如果拼的是 DDL，同样触发
应用层怎么提前发现混入了隐式提交
不能靠人工 review SQL 字符串，得看运行时行为：
- 在关键逻辑前加日志：记录
conn.get_autocommit()和conn.in_transaction()（PyMySQL / mysql-connector-python 支持） - 用
general_log抓真实执行流：开启后搜ALTER或DROP出现的位置，再看它前后有没有INSERT/UPDATE被ROLLBACK丢弃——如果没丢，说明中间被切开了 - 监控
Com_alter_table、Com_drop_table等状态变量突增，结合应用发布节奏判断是否误入事务块 - Navicat/DBeaver 执行多语句时，勾选“自动提交”但未识别某条是 DDL，最容易漏掉——这类客户端不会警告，只会静默提交
为什么 ROLLBACK 后还报权限错误
比如 ERROR 1370 (42000): execute command denied 或 ERROR 1373 (HY000): Cannot modify an existing transaction，这不是权限配置错了，而是事务已经不存在了：
- DDL 执行后，当前事务终结，连接回到“无事务”状态
- 此时再调
conn.rollback()实际无效，而紧接着的conn.commit()就会触发 MySQL 内部状态校验失败，抛出看似无关的权限类错误 - 典型误写：
try { ... } catch { conn.rollback(); conn.commit(); }—— rollback 后 commit 必然失败 - 修复方式：始终用
if conn.in_transaction(): conn.rollback()，避免无条件调用
