IN子句空参数检查致存储过程执行缓慢的问题排查

核心问题根源 #

1. 执行计划复用陷阱
   当你用OR @DETAIL_IDs IS NULL或AND @DETAIL_IDs IS NULL这类条件拼接时，SQL Server会生成一个通用执行计划，试图适配参数为NULL和非NULL两种场景。但百万级表的最优计划在两种场景下完全不同：参数非NULL时需要走ID列索引过滤，参数为NULL时需要全表扫描（或合适的覆盖索引扫描）。通用计划无法兼顾，导致参数为NULL时强制使用了低效的执行路径。

2. 隐式转换与函数开销
   如果表中的ID是数值类型（比如int），而你用varchar类型的@DETAIL_IDs通过CHARINDEX之类的函数匹配，会触发隐式类型转换——数据库会把表中所有ID转换成varchar去匹配函数条件，直接导致ID列的索引失效。哪怕参数为NULL，这种函数条件的存在也可能让执行计划判断混乱，额外消耗资源。

3. 条件逻辑的写法缺陷
   不管是OR还是AND的写法，本质上都是让SQL Server在一次查询中处理两种逻辑分支，这种“一刀切”的写法无法让数据库针对不同参数场景生成最优计划。

可行解决方案 #

• 拆分逻辑为分支查询
  直接用IF语句分情况执行，让两种场景各自生成最优执行计划：

  IF @DETAIL_IDs IS NULL
  BEGIN
      -- 参数为NULL时，执行不带ID过滤的查询
      SELECT t1.*, t2.*
      FROM Table1 t1
      JOIN Table2 t2 ON t1.ID = t2.DetailID
      -- 其他业务条件
  END
  ELSE
  BEGIN
      -- 参数非NULL时，拆分ID列表并过滤
      SELECT t1.*, t2.*
      FROM Table1 t1
      JOIN Table2 t2 ON t1.ID = t2.DetailID
      JOIN STRING_SPLIT(@DETAIL_IDs, ',') s ON t2.DetailID = CAST(s.value AS INT)
      -- 其他业务条件
  END
  

  这种写法会让数据库分别为两个分支生成最适合的执行计划，参数为NULL时直接走高效的全表/覆盖索引扫描，避免执行计划复用的问题。

• 优化ID列表的处理方式
  放弃CHARINDEX这类模糊匹配函数，改用STRING_SPLIT（SQL Server 2016+支持）将逗号分隔的字符串拆成行，再通过等值连接匹配ID列，同时显式转换类型避免隐式转换，确保ID列的索引可以被正常使用。

• 检查并优化索引
  确认两张表的关联列（比如Table2.DetailID）和查询中用到的过滤列、返回列是否有合适的覆盖索引。比如针对参数非NULL的场景，创建包含关联列和查询所需字段的非聚集索引；针对参数为NULL的场景，创建覆盖查询所有返回字段的索引，避免键查找带来的额外开销。

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