MySQL事务回滚失败主因是autocommit=1导致未真正开启事务；需先查@@autocommit=0，再用BEGIN显式启事务；DDL会隐式提交，SAVEPOINT仅标记回退点，ROLLBACK后连接状态不变，验证须查数据而非仅看提示。
MySQL 事务回滚失败的常见原因
执行 ROLLBACK 没反应、数据没变回去，大概率不是语法错，而是事务根本没真正开启——MySQL 默认是自动提交模式（autocommit=1），每条语句自己就是一个事务，执行完立刻提交，ROLLBACK 找不到可回滚的上下文。
- 先查当前会话是否关了自动提交：
SELECT @@autocommit;，返回0才算手动事务模式 - 显式开启事务用
BEGIN或START TRANSACTION，不能只靠SET autocommit = 0就以为万事大吉——它只是关提交，不建事务边界 - DDL 语句（如
CREATE TABLE、ALTER TABLE）会隐式触发COMMIT，导致前面的 DML 无法回滚，这点容易被忽略 - 如果用了存储过程或触发器，里面含 DDL 或某些系统函数（如
GET_LOCK()），也可能提前提交
SAVEPOINT 在嵌套操作中的实际用法
SAVEPOINT 不是“子事务”，它只是在当前事务内打个标记点，供 ROLLBACK TO SAVEPOINT 回退到该位置，不影响后续语句继续执行。适合补救部分出错但不想整个放弃的场景，比如批量导入时某几条数据校验失败。
- 定义：用
SAVEPOINT sp_name，名字随意但别重复；回退用ROLLBACK TO SAVEPOINT sp_name - 注意
RELEASE SAVEPOINT sp_name只是删标记，不影响数据；而ROLLBACK（无TO）会清掉所有保存点并结束整个事务 - 同一个事务中可以多次定义同名
SAVEPOINT，后定义的会覆盖前一个，不会报错 - 不支持跨连接共享，每个会话的
SAVEPOINT彼此隔离
ROLLBACK 后连接状态与连接池的影响
执行 ROLLBACK 只是回退事务里的变更，并不会断开连接、重置会话变量或释放锁（除非事务真正结束）。在连接池环境下，这可能引发意料之外的数据残留或锁等待。
- 事务结束后，表级锁、行锁通常释放，但元数据锁（MDL）可能持续到语句执行完才松开，尤其在长事务 + DDL 场景下容易卡住其他会话
- 连接池（如 HikariCP、Druid）归还连接前一般会执行
rollback，但前提是配置了rollbackOnReturn=true；否则未提交的事务可能“挂着”进入下一次复用，造成脏读或死锁 - 会话级设置（如
SET SESSION sort_buffer_size = ...）不受ROLLBACK影响，得靠RESET或连接重建来清理
如何验证 ROLLBACK 是否真的生效
别只信客户端显示“Query OK”，得看数据本身。尤其当涉及多表、外键或触发器时，表面回滚成功，实际可能因约束异常被截断或触发隐式行为。
- 最直接方式：在
ROLLBACK前后都查关键记录，用SELECT ... FOR UPDATE或加SELECT验证行内容和版本号（如_rowid或时间戳字段） - 检查事务状态：
SELECT TRX_ID, TRX_STATE, TRX_QUERY FROM INFORMATION_SCHEMA.INNODB_TRX WHERE TRX_MYSQL_THREAD_ID = CONNECTION_ID();，回滚后应查不到对应记录 - 若用的是 MySQL 8.0+，可开
performance_schema抓事务事件：UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME = 'events_transactions_current'; - 注意：MyISAM 表不支持事务，
ROLLBACK对它完全无效，连警告都不会报
