SQL存储过程传入日期参数执行耗时远长于内部声明变量问题咨询

数据老陈

2026-10-4

性能差异核心原因

两种写法本身没有语法错误，执行效率差距是SQL Server执行计划生成逻辑的差异导致的，本质是「参数嗅探」特性和局部变量基数估计规则的不同：

内部声明局部变量的场景：
存储过程编译阶段，局部变量的具体值对优化器是不可见的，优化器只能基于统计信息的平均密度做基数估计，该估计结果刚好适配你当前查询的数据分布，生成的执行计划是最优的，因此仅需20秒即可返回结果。
传入参数的场景：
存储过程的输入参数会触发「参数嗅探」特性：存储过程第一次执行时，优化器会用你传入的第一个参数值生成对应执行计划并缓存，后续所有调用都会复用该缓存计划。如果首次传入的参数对应的数据量极小，优化器大概率会生成嵌套循环这类适合小数据集的执行计划，当后续传入的参数对应大数据集时，该计划完全不适配，就会出现执行超时的情况。

常见解决方案

方案1：查询末尾添加重编译提示，适合报表类低频次执行的存储过程，每次调用都基于当前参数生成适配的执行计划：
```
SELECT ..... OPTION (RECOMPILE)
```

方案2：将输入参数赋值给内部局部变量，后续查询改用局部变量过滤，回到第一种场景的基数估计逻辑，规避参数嗅探影响：

CREATE PROCEDURE [dbo].[Month_OP_CL]  
(
    @RptDate DATE
)
AS
BEGIN   
    DECLARE @InnerRptDate DATE = @RptDate;
    SELECT ..... -- 过滤条件使用@InnerRptDate替代@RptDate
END;