SQL存储过程不支持真正多层嵌套事务，因数据库引擎仅允许单连接一个活跃事务；所谓“嵌套”实为中断重置或隐式提交，导致回滚失败、锁残留甚至死锁。
SQL存储过程中根本不能实现多层嵌套事务控制——这不是语法限制，而是数据库引擎的底层模型决定的。MySQL和SQL Server都只允许单连接一个活跃事务，所谓“嵌套”，只是让@@TRANCOUNT失真或触发隐式提交，最终导致回滚失败、锁残留甚至死锁。
为什么BEGIN TRANSACTION和START TRANSACTION在过程里会破坏外层事务
这两条语句不是压栈操作，而是中断+重置：MySQL执行START TRANSACTION时会立刻提交前一个未结束的事务；SQL Server执行BEGIN TRANSACTION只给@@TRANCOUNT加1，但任意ROLLBACK都会把它清零，外层事务瞬间失效。
- 典型报错：
ERROR 1305 (42000): SAVEPOINT does not exist（MySQL）、Msg 266, Level 16（SQL Server） - 更隐蔽的问题：外层已
INSERT的数据，在进存储过程后被START TRANSACTION隐式提交，后续ROLLBACK再也撤不回 - 验证方式：执行前查
SELECT @@TRANCOUNT（SQL Server）或SELECT @@autocommit（MySQL），确保调用方已设AUTOCOMMIT = 0
唯一可用的“分层回滚”手段是SAVEPOINT，但有硬性约束
SAVEPOINT不是新事务，只是当前事务内的标记点，它能ROLLBACK TO SAVEPOINT，但不释放锁、不改变@@TRANCOUNT、也不支持动态命名。
-
DECLARE EXIT HANDLER FOR SQLEXCEPTION必须写在SAVEPOINT sp_name之前，否则异常触发时找不到保存点 - 保存点名必须是字面量，如
sp_update_user，不能是变量@sp_name；同名会被覆盖，建议带上下文前缀 -
ROLLBACK TO SAVEPOINT后，事务仍处于活跃状态，必须由最外层显式COMMIT或ROLLBACK才能释放所有锁 - 锁不会自动释放：该点之后获取的行锁、间隙锁全留着，高并发下极易阻塞或触发
ERROR 1205死锁
真正可控的方案是扁平化 + 应用层统一事务边界
把“嵌套逻辑”拆成原子存储过程，由调用方用单个事务包裹，并严格约定锁序和执行顺序。
- 例如转账业务，不要写一个大过程含扣款+入账+记日志，而应拆为三个小过程：
proc_deduct、proc_credit、proc_log - 应用层用
BEGIN TRAN包住三者调用，并强制按accounts → transactions → audit_log顺序执行 - 每个小过程开头加注释声明锁依赖，如
-- LOCK ORDER: accounts，避免不同服务反向加锁形成闭环 - 批量操作必须分批，比如用
TOP (500)循环，每批后COMMIT，避免单次锁住上万行
最难处理的从来不是怎么写SAVEPOINT，而是误以为回滚了数据就等于释放了资源——锁生命周期始终绑定最外层事务，你回滚到保存点，别人还在等那几行锁。这点在可重复读隔离级别下几乎无法察觉，直到出现长时间阻塞或死锁才暴露。
