WHERE子句优化在UNION场景失效的原因及优化方案咨询

问题原因 #

你遇到的情况其实是SQL优化器的常见局限性：虽然从逻辑上看，当@include=0时，SELECT * FROM Set3 WHERE @include = 1 AND ...这部分肯定不会返回任何数据，但优化器并不一定能提前识别并完全跳过这部分查询的执行计划生成与前期评估。

具体来说，核心原因有两个：

• 如果@include是运行时变量（比如存储过程参数、会话变量），优化器在编译阶段无法确定它的具体值，所以会生成一个通用执行计划，包含所有分支的逻辑——哪怕运行时该分支不会返回数据，前期的表访问、条件解析等操作可能还是会执行。
• 多数数据库的优化器默认不会对这种变量驱动的条件做常量折叠优化，也就是不会把@include=0代入条件后直接剔除整个UNION分支。

可行的优化方法 #

1. 使用参数化动态SQL

直接根据@include的值动态拼接SQL语句，这样当@include=0时，完全不生成最后一段UNION代码，从根源上避免无效分支的执行。

示例（以SQL Server为例）：

DECLARE @sql NVARCHAR(MAX)
SET @sql = N'
SELECT * FROM (
 SELECT * FROM Set1 WHERE someConditions
 UNION
 SELECT * FROM Set2 WHERE someConditions'

IF @include = 1
BEGIN
 SET @sql += N'
 UNION
 SELECT * FROM Set3 WHERE otherConditions'
END

SET @sql += N') as t ORDER BY ...'

-- 用参数化方式执行，避免SQL注入风险
EXEC sp_executesql @sql

优点：完全消除无效分支，性能最优；缺点：需要处理动态SQL的写法，务必用参数化而非字符串拼接变量来规避注入风险。

2. 用IF/ELSE分支拆分查询

针对@include的两种值，分别编写完整的查询语句，让优化器为每种情况生成独立的最优执行计划。

示例：

IF @include = 1
BEGIN
 SELECT * FROM (
  SELECT * FROM Set1 WHERE someConditions
  UNION
  SELECT * FROM Set2 WHERE someConditions
  UNION
  SELECT * FROM Set3 WHERE otherConditions
 ) as t ORDER BY ...
END
ELSE
BEGIN
 SELECT * FROM (
  SELECT * FROM Set1 WHERE someConditions
  UNION
  SELECT * FROM Set2 WHERE someConditions
 ) as t ORDER BY ...
END

优点：优化器能为每个分支生成针对性的最优计划，执行效率稳定；缺点：存在代码冗余，如果查询逻辑复杂，后期维护成本会增加。

3. 强制查询重编译（OPTION(RECOMPILE)）

在查询末尾添加OPTION(RECOMPILE)，让优化器在运行时根据@include的实际值重新生成执行计划，此时优化器能识别出无效分支并跳过它。

示例：

SELECT * FROM (
 SELECT * FROM Set1 WHERE someConditions
 UNION
 SELECT * FROM Set2 WHERE someConditions
 UNION
 SELECT * FROM Set3 WHERE @include = 1 AND otherConditions
) as t ORDER BY ...
OPTION(RECOMPILE)

优点：无需修改查询结构，只需添加一个选项；缺点：每次执行都会重新编译查询，会增加CPU开销，适合查询执行频率不高的场景。

4. 改用UNION ALL（如果允许的话）

如果你的三个数据集本身没有重复数据，把UNION改成UNION ALL，优化器可能更容易识别无效分支。因为UNION需要去重，优化器可能会保留分支以完成去重逻辑，而UNION ALL不需要，当分支无数据时更容易被跳过。

示例：

SELECT * FROM (
 SELECT * FROM Set1 WHERE someConditions
 UNION ALL
 SELECT * FROM Set2 WHERE someConditions
 UNION ALL
 SELECT * FROM Set3 WHERE @include = 1 AND otherConditions
) as t ORDER BY ...

优点：修改成本低，优化器更易优化；缺点：仅适用于数据集无重复的场景，否则会返回重复数据。

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