应先用select @@in_transaction确认事务状态，值为1表示活跃，0表示已隐式提交；再查information_schema.innodb_trx看trx_state是否为running或lock wait；最后执行show warnings排查静默错误。
查@@in_transaction确认事务是否还“活着”
事务回滚失败，第一反应不该是翻代码，而是立刻验证当前连接是否真处于事务中。MySQL 8.0+ 提供了可靠的运行时指标：SELECT @@in_transaction。值为 1 表示事务活跃，0 就说明已被隐式提交或已结束——后续任何 ROLLBACK 都只是对空事务的无效操作。
实操建议：
- 在关键 DML 后、DDL 前、以及
ROLLBACK前各执行一次SELECT @@in_transaction，观察值何时从1变成0 - 避免只查
@@autocommit：它为1时每条语句自动提交，但它为0也不代表事务一定还在——DDL 会把它“劫持”掉 - 应用层（如 Python 的
mysql-connector-python）可用conn.in_transaction()方法替代 SQL 查询，更及时
盯住ALTER TABLE、GRANT这类隐式提交语句
DDL 和 DCL 是最常见的“事务终结者”。只要它们出现在 BEGIN 和 COMMIT 之间，前面所有 DML 就已落地。不是回滚失效，而是根本没东西可滚。
常见错误现象：
- 事务块里先
INSERT INTO log，再ALTER TABLE user ADD COLUMN phone，最后ROLLBACK→ 日志记录仍在 - 用 Navicat 批量执行多条语句时勾选了“自动提交”，但某条
CREATE INDEX混在中间，导致前序语句被悄悄提交 - 存储过程中动态拼接
SET @sql = 'ALTER TABLE ...'; PREPARE stmt FROM @sql; EXECUTE stmt;→ 同样触发隐式提交
注意：TRUNCATE TABLE、DROP USER、FLUSH PRIVILEGES 全部属于同一类，不能凭“看起来像 DML”就放松警惕。
用INFORMATION_SCHEMA.INNODB_TRX抓活跃事务快照
光看变量不够直观，要直接看到事务是否还在跑。查询 INFORMATION_SCHEMA.INNODB_TRX 能暴露真实状态：
SELECT TRX_ID, TRX_STATE, TRX_STARTED, TRX_QUERY FROM INFORMATION_SCHEMA.INNODB_TRX WHERE TRX_MYSQL_THREAD_ID = CONNECTION_ID();
重点关注 TRX_STATE 字段：
-
RUNNING：事务正常执行中 -
LOCK WAIT：正在等锁，可能即将超时或死锁 - 查询无结果或
TRX_STATE为空：事务已结束（大概率已被隐式提交）
这个查询必须在执行可疑语句（如 ALTER）前后各跑一次，对比结果才能定位“哪一行让事务消失了”。
别忽略SHOW WARNINGS和错误日志里的静默失败
有些隐式提交不是因为语句本身，而是因为触发器或存储过程内部出错后被吞掉了错误，导致主语句看似成功，实际事务已中断。此时 ROLLBACK 依然无效，但你根本不知道哪里断了。
实操建议：
- 每次执行完 INSERT/UPDATE/DELETE 后，**立刻**执行
SHOW WARNINGS，尤其当返回 “0 rows affected” 却没报错时 - 检查 MySQL 错误日志路径：
SELECT @@log_error，确认log_error_verbosity = 3（MySQL 8.0+），否则触发器内的警告不会落盘 - 若触发器里写了
SIGNAL或访问了不存在的列（如NEW.invalid_col），错误往往只藏在SHOW WARNINGS里，不抛给客户端
真正棘手的不是显式报错，而是那些没提示、没日志、数据却不对的“幽灵提交”——它们通常发生在跨库操作漏写库名、触发器内 SELECT 未接 INTO、或 sql_mode 缺少 STRICT_TRANS_TABLES 的时候。
