mysql不支持事务嵌套，start transaction会隐式提交当前事务并重置，savepoint是唯一可实现局部回滚的机制，需注意命名唯一、声明顺序及锁残留问题。
MySQL根本不支持事务嵌套，所谓“嵌套事务导致的异常回滚”本质上是误用 START TRANSACTION 或混淆了保存点与事务边界的后果。排查这类问题，核心不是找“嵌套”，而是定位“隐式提交”和“保存点失效”这两个真实诱因。
为什么START TRANSACTION在存储过程中会破坏事务连续性
MySQL 的事务模型是会话级、扁平化的：同一连接只允许一个活跃事务。在存储过程里执行 START TRANSACTION，会立刻提交当前已开启但未结束的事务（哪怕由调用方显式开启），然后新建一个事务——这不是嵌套，是中断加重置。
- 典型现象：
INSERT后跟START TRANSACTION，再ROLLBACK，结果发现第一条INSERT已写入磁盘且不可逆 - 更隐蔽的问题：存储函数中直接写
START TRANSACTION会报错ERROR 1422 (HY000)，因为函数/触发器内禁止隐式或显式提交 - 验证方式：在调用前后查
SELECT * FROM information_schema.INNODB_TRX，会看到trx_id突然变更，且旧事务状态变为COMMITTED
SAVEPOINT 失效的常见原因和检查点
SAVEPOINT 是唯一能模拟局部回滚的机制，但它极易因声明顺序、命名冲突或锁残留而失效。
-
DECLARE EXIT HANDLER FOR SQLEXCEPTION必须在SAVEPOINT sp_name之前定义，否则 handler 触发时找不到保存点，报ERROR 1305 (42000): SAVEPOINT does not exist - 同名
SAVEPOINT会被覆盖（不报错），但后续ROLLBACK TO SAVEPOINT实际回滚到的是最后一个同名点，容易误判逻辑边界 -
ROLLBACK TO SAVEPOINT不释放锁：它只撤销数据变更，但行锁、间隙锁仍被持有。长事务中频繁设点+回滚，可能堆积锁并引发ERROR 1205 (HY000): Deadlock found - 验证锁是否残留：查
performance_schema.data_locks，过滤对应线程 ID 和事务 ID
如何确认回滚行为是否符合预期
不能只看 SQL 是否执行成功，要结合事务状态、锁行为和引擎日志交叉验证。
- 执行
SHOW ENGINE INNODB STATUS\G后重点看TRANSACTIONS部分：若看到trx_state = 'ROLLING BACK'持续数秒以上，说明回滚本身正在等锁，而非业务逻辑触发了回滚 - 查
INNODB_TRX中的trx_started和trx_weight：权重值极大（如 > 10000）往往意味着 undo log 量大，回滚慢；时间戳远早于当前时间说明是长事务残留 - 对比
SELECT * FROM mysql.general_log WHERE argument LIKE '%ROLLBACK%'和应用层日志：如果应用没发ROLLBACK，但日志里出现，大概率是连接异常断开后 MySQL 自动回滚 - 注意 DDL 的隐式提交：在事务中执行
ALTER TABLE会立刻提交前面所有 DML，此时再ROLLBACK已无效
真正棘手的从来不是“怎么回滚”，而是“回滚到底撤回了什么”。保存点命名带上下文（比如 sp_charge_validation）、事务开头加注释（-- TX: refund processing for order #123）、以及避免在事务里做任何非数据库操作——这些细节比语法本身更容易决定一次回滚是否干净。
