事务回滚失败主因是表引擎非InnoDB、autocommit开启、隐式提交语句触发、undo日志空间不足；需先确认ENGINE=InnoDB、SET autocommit=0、避免DDL语句、检查INNODB STATUS及磁盘空间。
事务回滚失败时先确认是否真在 InnoDB 表上操作
MySQL 事务只对 InnoDB 引擎生效，MyISAM 等引擎根本不支持事务，执行 ROLLBACK 不报错但实际无效果。常见现象是：明明执行了 BEGIN 和修改语句，再 ROLLBACK 后数据却没恢复。
- 用
SHOW CREATE TABLE `table_name`查看表引擎，确认输出中含ENGINE=InnoDB - 建表时没显式指定引擎，默认可能不是
InnoDB（尤其老版本或自定义配置） - 复制表或导入 SQL 时，
CREATE TABLE ... SELECT或mysqldump可能保留原引擎，不自动转为InnoDB
检查 autocommit 是否被意外关闭或开启
autocommit 状态直接影响 ROLLBACK 是否起作用。如果它为 ON，每条语句都是独立事务，BEGIN 后没显式 COMMIT 或 ROLLBACK，连接断开或语句结束就自动提交了——此时再执行 ROLLBACK 已无事务可回滚。
- 查当前状态：
SELECT @@autocommit，返回1表示开启，0表示关闭 - 交互式使用时，建议显式用
SET autocommit = 0关闭，再BEGIN，避免依赖默认行为 - 应用代码里（如 Python 的
pymysql、Java 的JDBC）要注意连接初始化时的autocommit设置，别被框架默认值误导
回滚失败但没报错？可能是隐式提交语句中途触发了提交
某些 SQL 语句会**强制触发隐式提交**，导致 BEGIN 后的事务提前结束。这时再 ROLLBACK 就只能回滚空事务，看起来“失败”。
- 典型隐式提交语句包括：
CREATE TABLE、DROP TABLE、ALTER TABLE、TRUNCATE TABLE、LOCK TABLES、GRANT、REVOKE - 例如：在事务中执行
CREATE TEMPORARY TABLE不会隐式提交，但CREATE TABLE会 - 执行
SHOW ENGINE INNODB STATUS查看TRANSACTIONS部分，若Trx state显示NOT STARTED，说明事务已结束
日志空间不足或 innodb_log_file_size 配置过小也会让回滚卡住
大事务回滚需要足够大的 undo log 空间来记录反向操作。如果 innodb_log_file_size 太小，或磁盘满、innodb_undo_tablespaces 耗尽，回滚可能卡在“rolling back”状态，表现为长时间无响应，而非立刻报错。
- 查当前回滚进度：
SHOW ENGINE INNODB STATUS\G，关注TRANSACTIONS下的ROLLING BACK行和undo log entries数量 - 监控
innodb_os_log_pending_fsyncs和磁盘df -h，排除 I/O 或空间瓶颈 - 生产环境避免单事务修改超 10 万行；真要大批量更新，拆成小事务 + 显式
COMMIT
ALTER TABLE 或自动提交带走了。 
