如何优化WHERE子句中含CASE判断的SQL查询执行性能？

你当前使用的列 = CASE WHEN @参数 = -1 THEN 列 ELSE @参数 END写法属于典型的非SARG查询：筛选列被包裹在CASE表达式中，数据库查询优化器无法利用ID1/ID2/ID3列上的索引，多数情况下会生成全表扫描的执行计划；同时不同参数取值下最优执行计划差异极大，执行计划缓存复用很容易触发参数嗅探问题，这就是部分场景下性能极差的核心原因。

方案1：布尔逻辑改写（适配大多数场景） #

将CASE表达式改写为参数判断+列匹配的OR逻辑，避免对筛选列做运算，让优化器可以识别索引使用条件：

DECLARE @ID_1 int = -1, @ID_2 int = 123, @ID_3 int = -1

SELECT ...
FROM...
WHERE 
    (@ID_1 = -1 OR tblA.ID1 = @ID_1)
    AND (@ID_2 = -1 OR tblB.ID2 = @ID_2)
    AND (@ID_3 = -1 OR tblC.ID3 = @ID_3)
    -- 其余筛选条件按相同规则改写
    OPTION (RECOMPILE)

注意：你原语句中第三个CASE的THEN分支写的是tblB.ID3，属于跨表引用，如果不是业务特殊要求，这里属于笔误，会导致@ID_3=-1时触发非预期的跨表等值判断，额外拖慢查询速度。

语句末尾加的OPTION (RECOMPILE)提示会让数据库每次执行时根据当前传入的实际参数生成最优执行计划，避免错误的缓存计划复用，这个提示的编译开销在大多数业务场景下可以忽略。

方案2：动态SQL拼接（适配多筛选条件、大数据量场景） #

如果可选筛选条件数量多，方案1改写后优化器仍无法生成理想执行计划，可以使用动态SQL仅拼接当前生效的筛选条件，从根源上消除无效判断逻辑，执行效率最高：

DECLARE @ID_1 int = -1, @ID_2 int = 123, @ID_3 int = -1
DECLARE @execSql NVARCHAR(MAX)

-- 基础查询语句
SET @execSql = N'
SELECT ...
FROM...
WHERE 1=1'

-- 仅拼接参数不为-1的筛选条件
IF @ID_1 <> -1
    SET @execSql = @execSql + N' AND tblA.ID1 = @ID_1'
IF @ID_2 <> -1
    SET @execSql = @execSql + N' AND tblB.ID2 = @ID_2'
IF @ID_3 <> -1
    SET @execSql = @execSql + N' AND tblC.ID3 = @ID_3'
-- 其余筛选条件按相同规则追加

-- 参数化执行，避免SQL注入，同时支持执行计划复用
EXEC sp_executesql @execSql,
    N'@ID_1 int, @ID_2 int, @ID_3 int',
    @ID_1 = @ID_1, @ID_2 = @ID_2, @ID_3 = @ID_3

这个写法最终执行的语句只包含实际需要的筛选条件，优化器可以精准匹配对应列的索引做查找，没有多余逻辑干扰，是这类多可选参数查询性能最好的实现方式。

• 确认tblA.ID1、tblB.ID2、tblC.ID3三个高频筛选列上建有对应索引，否则任何写法都无法获得理想的查询性能。
• 如果使用方案1，不要省略RECOMPILE提示，否则大概率还是会遇到参数嗅探导致的性能波动。

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