sql存储过程中不存在真正嵌套事务，start transaction或begin transaction仅触发隐式提交或增加@@trancount，破坏事务一致性；唯一安全方案是调用方控制事务边界，过程内用savepoint（mysql）或save transaction（sql server）实现局部回滚，且需注意锁不释放、命名须字面量、异常处理器须前置。
SQL存储过程里根本不存在真正的嵌套事务——无论你写多少次 BEGIN TRANSACTION 或 START TRANSACTION，数据库都只认一个活跃事务。所谓“嵌套”，只是徒增 @@TRANCOUNT 计数或触发隐式提交，反而让回滚行为失控、锁持有时间拉长、死锁风险飙升。
MySQL 存储过程中执行 START TRANSACTION 会立刻提交前一个事务
这是最常踩的坑：你在应用层已开启事务，调用一个内部含 START TRANSACTION 的存储过程，结果刚进过程那条 INSERT 就落库了，再也 Rollback 不回去。
- 错误现象：
ERROR 1305 (42000): SAVEPOINT does not exist，或发现“回滚后数据还在”，其实是前一段早被隐式提交 - 根本原因：MySQL 事务模型是扁平的，单连接同一时刻只能有一个活跃事务；
START TRANSACTION不是压栈，是中断+重置 - 正确做法：存储过程体内绝不写
START TRANSACTION和COMMIT，由调用方统一控制事务边界 - 验证方式：执行前确认
AUTOCOMMIT = 0，否则SAVEPOINT无效
SQL Server 中 SAVE TRANSACTION 是唯一可控的“局部回滚”手段
SAVE TRANSACTION 不创建新事务，只在当前事务内打一个锚点；ROLLBACK TRANSACTION savepoint_name 能撤回该点之后的变更，且 @@TRANCOUNT 不变——这才是你真正需要的“分段控制”。
- 必须前置条件：执行
SAVE TRANSACTION前，@@TRANCOUNT > 0，否则报错Msg 628 - 命名限制：保存点名必须是字面量（如
savepoint_orderdetails），不能是变量；动态拼接需用PREPARE+EXECUTE，但有 SQL 注入风险 - 典型误用：子过程自己写
BEGIN TRANSACTION+ROLLBACK，导致外层事务计数不匹配，抛出Msg 266 - 安全模式：外层过程设点 → 调用子过程 → 出错时回滚到点 → 继续后续逻辑或最终
COMMIT
SAVEPOINT / SAVE TRANSACTION 回滚后锁不会自动释放
很多人以为 ROLLBACK TO SAVEPOINT 或 ROLLBACK TRANSACTION savepoint_name 会“清理干净”，其实它只撤销数据修改，不释放该点之后语句持有的行锁、间隙锁——这些锁会一直卡着，直到整个事务 COMMIT 或最终 ROLLBACK。
- 高并发下极易阻塞其他查询，甚至触发
ERROR 1205 (HY000): Deadlock found when trying to get lock - 验证残留锁：查
performance_schema.data_locks（MySQL）或sys.dm_tran_locks（SQL Server） - 批量操作必须分批：用
TOP (500)或LIMIT 500循环处理，每批后COMMIT，避免单次锁住上万行 - 索引缺失是放大器：检查执行计划中是否出现
Clustered Index Scan或Index Scan，没索引的WHERE条件会让锁范围失控
真正可靠的方案是拆成原子过程 + 应用层统一事务
别再试图在存储过程里模拟嵌套逻辑。转账不是“扣款+入账+记日志”一个大过程，而是三个独立存储过程，由应用层用单个事务包裹，并强制按 accounts → transactions → audit_log 顺序访问。
- 每个小过程开头加注释声明锁序：
-- LOCK ORDER: accounts → transactions - 子过程只返回状态码（如
INT输出参数），由外层决定是否回滚整段 - 跨服务调用必须约定全局锁顺序并文档化，否则订单服务按
orders → users、用户服务按users → orders，死锁闭环就形成了 - 所有被调用过程的
WHERE字段必须有索引，且类型严格匹配（INT字段别传字符串）
复杂点不在语法，而在锁生命周期和事务边界的归属判断——存储过程只该负责逻辑分段，不该承担事务决策。一旦把 COMMIT 或 ROLLBACK 塞进过程体，你就已经把并发安全交给了不可控的调用链。
