不能直接改而是要拆分，因其逻辑耦合紧、嵌套深、隐式依赖多（如临时表、SET选项、ANSI_NULLS等），修改风险远高于重构；应按职责边界拆为校验、查询、计算三部分，并用Composite包装协调。
为什么不能直接改 sp_GetUserOrderSummary 而要拆？
因为这类存储过程往往同时做权限校验、数据聚合、临时表拼接、结果分页、甚至写日志——逻辑耦合紧，改一处常牵出三个 NULL 异常或 Conversion failed when converting date 错误。不是“不能改”，而是每次修 bug 都得重读 300 行嵌套 IF 和游标，风险远高于重构。
- 修改前先确认它是否被其他过程用
EXEC显式调用（查sys.dm_exec_referencing_entities） - 检查是否有应用层直连调用该过程名（比如 C# 里硬编码了
"sp_GetUserOrderSummary"） - 临时表命名若为
#tmp_result这类泛化名，大概率在子逻辑里被反复INSERT INTO #tmp_result，这是拆分时最易漏掉的隐式依赖
怎么安全拆：从「副作用」和「返回值」切分
核心原则：每个新过程只做一件事，且副作用可控（比如只读、只写一张表、只发一条日志）。不要按“步骤顺序”拆（如“第一步查用户，第二步查订单”），而要按“职责边界”拆。
-
usp_ValidateUserAccess：只校验@UserId是否有效、是否有对应租户权限，返回BIT或抛错，不查任何业务数据 -
usp_GetUserOrdersRaw：只查Orders和关联OrderItems，用明确字段列表（不用*），加WITH (NOLOCK)注释说明用途，不带分页 -
usp_CalculateOrderSummary：输入是上一步的结果集（用表值参数@OrderList dbo.OrderTableType），只做SUM/COUNT/日期分组，不碰数据库表
注意：SQL Server 的表值参数必须提前定义类型，别等到写 usp_CalculateOrderSummary 才发现没建 dbo.OrderTableType，否则编译就报错。
调用链怎么组织才不掉坑？
别让应用层去串调多个过程——那等于把拆分前的复杂度搬到了代码里。用一个轻量包装过程来协调，但只负责组合，不掺逻辑。
- 包装过程名建议带
Composite后缀，比如usp_GetUserOrderSummary_Composite - 它内部用
DECLARE @ResultTable TABLE(...)接收中间结果，而不是一堆#temp（避免跨批作用域问题） - 所有子过程调用后，立刻检查
@@ERROR或用TRY...CATCH，但错误信息要重写，比如把"Cannot insert null into OrderDate"转成"Invalid order data for user {0}"，屏蔽底层细节 - 如果原过程用了
SET NOCOUNT ON，每个子过程也必须加，否则 C# 的SqlDataAdapter.Fill()会因多出的结果集而失败
性能退化比逻辑错更难排查
拆完跑得慢？大概率是丢失了原过程里隐式的执行计划复用，或者临时表统计信息失效。
- 原过程里
SELECT ... INTO #tmp自动生成统计信息，拆成多个过程后，usp_GetUserOrdersRaw返回表变量或 TVP，优化器可能选错连接方式 - 解决方法：对高频使用的表值参数类型，在调用方显式加
OPTION (RECOMPILE)，或给关键字段加索引（如OrderTableType上建INDEX IX_OrderId ON (OrderId)） - 另一个坑：原过程用
GETDATE()多次取时间，拆开后各子过程分别取，导致“同一笔订单在汇总和明细里时间戳差几毫秒”，影响幂等判断
拆的过程本身不难，难的是把原来藏在几百行里的上下文约束，一项项拎出来显式声明。没人会告诉你 sp_GetUserOrderSummary 默认要求调用者已开启 ANSI_NULLS，直到你拆完发现某个子过程在别人库里死活编译不过。
