sql server中嵌套调用存储过程合法但需严守规则：①output参数必须声明变量并加output关键字；②捕获结果集须用结构完全一致的临时表；③跨库调用需三段式名称并授权；滥用会导致锁延长、死锁及静默失败。
不应该一概避免，但必须严格约束使用场景和调用方式——嵌套本身合法且有用，问题出在滥用、隐式事务传递和参数/结果集处理不当上。
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 却拿不到数据——这种错没法从报错信息里直接看出。
