@var IS NULL条件引发聚集索引扫描的SQL查询改写方法咨询

你遇到的是可选参数查询的典型性能问题，原有写法里的OR条件会让优化器无法针对@var的实际值选择最优执行计划，导致忽略Col1上的索引，强制走聚集索引扫描。以下是三种成熟的优化方案：

方法1：用UNION ALL拆分逻辑 #

这是最简单的无额外开销方案，把两种参数场景拆分执行，优化器会自动跳过不满足条件的分支：

SELECT Column1, column2, ..., column30
FROM [Table]
WHERE @var IS NULL

UNION ALL

SELECT Column1, column2, ..., column30
FROM [Table]
WHERE Col1 = @var

• 适用场景：可选参数数量少（1-2个）、查询执行频率高的场景，没有重编译开销，逻辑易维护。

方法2：添加重编译提示 #

不用修改原有查询逻辑，只需要加查询提示让优化器每次执行时根据@var的实时值生成执行计划：

SELECT Column1, column2, ..., column30
FROM [Table]
WHERE (@var IS NULL OR Col1 = @var)
OPTION (RECOMPILE)

• 适用场景：查询执行频率低（比如后台报表、低频操作），可以接受每次执行的少量重编译开销的场景。

方法3：动态SQL拼接 #

根据参数是否为空动态生成查询条件，完全避免OR逻辑，同时可以复用不同参数场景的执行计划：

DECLARE @sql NVARCHAR(MAX) = N'SELECT Column1, column2, ..., column30 FROM [Table] WHERE 1=1 ';

IF @var IS NOT NULL
BEGIN
    SET @sql += N'AND Col1 = @var ';
END

EXEC sp_executesql 
    @sql,
    N'@var 你Col1字段的实际类型', -- 填写Col1的实际字段类型，比如INT、NVARCHAR(50)
    @var = @var;

• 适用场景：可选参数多、查询执行频率高的场景，性能最优，参数化写法可避免SQL注入风险。

额外注意事项 #

如果Col1上的是非聚集索引，且你需要查询的Column1到column30没有全部加到该索引的INCLUDE列表中，就算优化器选择了Col1的索引，也可能触发键查找操作，返回列过多时性能甚至不如聚集索引扫描。这种情况可以考虑调整索引，把需要返回的列加到INCLUDE中，或者直接使用覆盖索引。

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