在 SQL Server 中，嵌套调用存储过程到底能否使用？这是许多开发者常遇到的疑问，关键在于如何正确使用。
首先给出结论：没有必要完全避免嵌套调用。嵌套本身是合法且实用的功能，问题往往源于滥用、隐式事务传递以及参数或结果集处理不当。只要严格限定使用场景并规范调用方式，嵌套存储过程完全可以成为你工具库中的高效利器。
SQL Server 使用 EXEC 调用嵌套存储过程的硬性规则
直接使用 EXEC 调用另一个存储过程当然可行，但以下三点如果遗漏任何一项，就会导致静默失败或返回空值——这类错误常让人难以排查：
OUTPUT参数必须声明变量，并在调用时显式加上OUTPUT关键字，例如EXEC sp_calc @result OUTPUT；如果只写@result而不加OUTPUT，值不会回传，你得到的永远是空值- 若想捕获被调用过程的
SELECT结果集，必须使用临时表（如#tmp）来接收，且列名、数量、数据类型及顺序必须完全一致；注意，DECLARE @t TABLE(...)不能用于INSERT INTO @t EXEC ... - 跨库调用必须使用三段式名称，例如
EXEC [SalesDB].[dbo].[sp_get_order_summary]；如果只写sp_get_order_summary，可能会调到当前库的同名存储过程，尤其当多个数据库共用同一账号时，很容易引发混乱
嵌套调用如何悄然引发死锁与性能崩溃
表面上看嵌套调用实现了逻辑复用，但实际上它常常延长锁持有时间、扩大锁范围，而且问题往往被归结为“数据库慢”——这才是最隐蔽的坑：
- 嵌套并不等同于事务隔离：SQL Server 没有真正意义上的嵌套事务，
SAVE TRANSACTION只是回滚锚点；内层存储过程中的UPDATE操作会延长最外层事务的锁持有时间，不知不觉中锁就被卡住了 - 执行计划容易失控：内层存储过程如果包含
SELECT * FROM big_table WHERE id = @param，而@param是VARCHAR类型但字段是INT，就会触发隐式转换，导致全表扫描，锁住上万行，性能瞬间崩溃 - 锁顺序混乱：A 存储过程先锁定
orders表，再调用 B 存储过程锁定customers表，而 B 存储过程又反过来先锁定customers再查询orders表，死锁概率会急剧增加，这种循环依赖一旦出现，排查起来非常耗时
什么情况下该用嵌套，什么情况下必须拆分
判断依据不是“能不能用”，而是“是否应该将事务边界和锁控制权交给数据库”——这其实是一个权衡问题：
- 适合嵌套的场景：封装纯数据操作的原子动作，且不涉及外部依赖。例如
sp_deduct_inventory（扣库存）被sp_place_order调用，两者都只读写inventory表，无循环、无动态 SQL，这种场景下嵌套非常清晰高效 - 必须拆分的场景：涉及跨表强顺序、批量更新或需要分批提交。例如转账操作应拆分为
sp_debit_account→sp_credit_account→sp_log_transaction，由应用层使用单个事务包裹并固定锁顺序：accounts → transactions → audit_log，这样才安全 - 绝对禁止的场景：嵌套中调用
OPENQUERY、xp_cmdshell或包含WAITFOR的存储过程——它们不会释放锁却会卡住数秒，极易引发连锁等待，一旦出现这种问题，排查会非常痛苦
最容易被忽视的是：嵌套层级本身并不危险，危险的是开发者误以为 SAVE TRANSACTION 能实现局部回滚，结果异常未捕获导致整个外层事务全部丢失；此外，临时表结构没有对齐，虽然执行成功，但 SELECT 却拿不到数据——这种错误无法从报错信息中直接看出，只能依靠经验与严谨的排查流程来定位。
