存储过程与同参数SQL查询返回计数不一致问题求助

别担心，这种参数看似一致但结果差1的情况确实挺挠头的，我帮你梳理几个最可能的原因，你可以逐一排查：

• 参数类型/精度不匹配
  这是最常见的诱因！你得仔细核对存储过程中@StartDate和@EndDate的参数定义，是不是和常规查询里用的类型不一样？比如常规查询用的是DATETIME，但存储过程里定义成了DATE？
  如果是这种情况，当你传入带时间的日期（比如'2024-05-31 23:59:59'）到DATE类型参数时，会被自动截断成'2024-05-31 00:00:00'，BETWEEN条件会直接排除当天0点之后的所有记录，刚好就少了那1条导致计数差1。
  你可以对比存储过程的参数定义：比如CREATE PROCEDURE YourProc @StartDate DATE, @EndDate DATE和常规查询的参数类型是否完全一致。

• 存储过程存在额外过滤逻辑
  有没有可能存储过程里的完整SQL比你贴出的常规查询多了隐藏的过滤条件？比如是不是偷偷加了AND f.some_column IS NOT NULL或者其他你没注意到的限制？
  建议把存储过程里的SQL完整复制出来，和你的常规查询逐行对比，别放过任何细节。

• 参数传递的隐性错误
  有时候调用存储过程时，参数值可能和常规查询用的不一样！比如是不是@StartDate传成了晚一天的日期？或者@Location参数存在大小写差异（如果数据库排序规则是区分大小写的，'LOC_A'和'loc_a'会被当成不同值）？
  你可以在存储过程开头加一句SELECT @Location AS Proc_Location, @StartDate AS Proc_Start, @EndDate AS Proc_End，执行存储过程时先看输出的参数值，和常规查询用的参数完全对比一遍。

• 格式转换的细微差异
  你用到了CONVERT(VARCHAR, f.date_entered, 101)，虽然格式码是统一的，但要注意：如果存储过程里的VARCHAR没指定长度（写成CONVERT(VARCHAR, ...)而非CONVERT(VARCHAR(10), ...)），不同环境下的默认长度可能会有差异？不过这个可能性相对小，但也可以检查下存储过程里的转换语句是不是和常规查询完全一致。

• 存储过程执行计划缓存问题
  有时候存储过程的执行计划可能过时了，导致优化器选择了不正确的过滤方式，进而影响结果。你可以尝试重新编译存储过程：

  EXEC sp_recompile 'Your_Procedure_Name'
  

  之后再调用存储过程看看计数是否和常规查询一致。

另外，还有个实用的排查技巧：把存储过程里的完整SQL复制出来，替换成你用的参数值直接执行，看结果是21还是20。如果执行结果是21，那问题肯定出在参数传递或者存储过程的参数定义上；如果结果是20，那就是存储过程的SQL本身和常规查询有差异。

内容的提问来源于stack exchange，提问作者user3753620