先说一个在众多SQL Server项目中反复出现的误区：SQL Server并不真正支持嵌套事务。
许多开发者认为，在已有事务中再开启一个事务，就能实现逻辑隔离与局部回滚。但事实是，无论你执行多少次BEGIN TRANSACTION，都只是让系统计数器@@TRANCOUNT增加1而已。所有操作本质上仍隶属于最外层的那一笔事务——只要最终执行一次ROLLBACK，此前全部的数据修改都将被撤销。这完全违背了“嵌套事务”一词给人的直观理解。
典型的错误场景是这样的：开发者使用SA VE TRANSACTION sa vepoint_a建立了保存点，希望出错时能部分回滚。然而实际运行中，虽然ROLLBACK TRANSACTION sa vepoint_a执行成功，但后续若因异常处理不当又触发了一次全局ROLLBACK，那么包括保存点之前的所有操作也会一并丢失，导致数据恢复失败。
以下几个原则值得牢记：
SA VE TRANSACTION仅是一个回滚标记点，并非独立的事务边界，无法实现逻辑块的隔离。- 切勿在存储过程中手动增减
@@TRANCOUNT，尤其要避免在TRY/CATCH结构外直接书写BEGIN TRANSACTION。 - 若需分段控制回滚，建议在应用层拆分为多个独立的存储过程调用，让每个过程自主管理其事务生命周期。
嵌套调用如何悄然加剧死锁风险
表面上看，嵌套事务只是“在一个事务中执行多个操作”。但实际隐患在于，它会不可控地延长锁的持有时间。例如：事务A更新了orders表且尚未提交，紧接着又调用了另一个包含UPDATE customers操作的存储过程，而该过程复用了同一事务上下文。此时若事务B以相反顺序访问这两个表——死锁闭环便立刻形成。
更为隐蔽的是，嵌套调用常伴随隐式的锁范围扩大。比如内层过程执行SELECT * FROM order_items WHERE order_id = @id，但由于order_id字段缺少索引，导致全表扫描并升级为页锁，瞬间锁定成千上万行，远超业务实际需要的记录数。这类隐性锁扩张令人防不胜防。
排查时可关注以下几点：
- 观察执行计划是否出现
Clustered Index Scan或Index Scan，这是锁范围失控的关键信号。 - 确保所有被嵌套调用的存储过程中，
WHERE条件涉及的字段均已建立索引，且传入参数类型严格匹配（例如INT字段避免传入字符串）。 - 禁止在事务中调用含有外部依赖的过程（如
OPENQUERY、EXEC xp_cmdshell），这类操作不会释放锁，却可能长时间阻塞其他会话。
替代方案：逻辑扁平化与显式锁序设计
与其在存储过程中强行模拟嵌套事务，不如将业务逻辑拆分为原子操作，由调用方统一管理事务边界与表访问顺序。以转账场景为例，避免编写“扣款+入账+记日志”的巨型存储过程，而是拆分为三个独立小过程，在应用层通过单一事务进行封装，并强制按accounts → transactions → audit_log的顺序依次执行。
这种设计具有以下优势：
- 每个小型存储过程职责单一，可在开头通过注释声明锁序：
-- LOCK ORDER: accounts → transactions，清晰易懂。 - 批量操作必须采用分页处理，例如使用
TOP (500)配合循环，每批完成后立即COMMIT，避免单次事务锁定过多数据行。 - 对于跨服务调用，需约定全局锁顺序并形成文档。否则一旦订单服务按
orders → users顺序更新，而风控服务采用相反顺序，死锁必将重现。
真正的难点在于技术规范的落地执行
即使在测试环境中将锁顺序、索引覆盖、事务粒度都调整至最优，但只要有一位开发人员在新增存储过程中动态拼接表名、或在事务内加入HTTP调用、或忘记为新字段建立索引，高并发场景下的死锁仍可能在凌晨悄然发生。
最有效的防御措施其实是一份严谨的代码审查清单：每次提交PR时，都必须确认是否包含OPENQUERY、所有WHERE条件字段是否已建索引、是否声明了LOCK ORDER注释、@@TRANCOUNT是否被意外修改。这些细节上的审查，比任何自动化工具都更能从根本上预防问题。
