SQL Server中Union的替代方案有哪些？解决Union导致的查询性能下降问题

针对你遇到的Union导致查询耗时激增的问题，这里有几个实用的替代方案，能帮你把执行时间降下来：

• 优先用UNION ALL替代UNION（如果无重复数据）
  这是最容易踩的性能坑——UNION会自动对两个结果集做去重和排序操作，这两步在数据量较大时开销极大。如果你的第一部分查询结果和a.UI = 1414的结果没有重叠（或者业务允许返回重复数据），直接换成UNION ALL，性能会立竿见影地提升。
  示例：

  -- 原来的查询
  SELECT col1, col2, ... FROM your_table WHERE [原业务条件]
  UNION
  SELECT col1, col2, ... FROM your_table WHERE a.UI = 1414
  
  -- 优化后
  SELECT col1, col2, ... FROM your_table WHERE [原业务条件]
  UNION ALL
  SELECT col1, col2, ... FROM your_table WHERE a.UI = 1414
  

• 用OR逻辑合并查询条件
  如果两个查询的目标表相同、返回字段一致，可以把两个条件合并到同一个WHERE子句里，用OR连接。这样SQL Server只需要扫描一次表（或索引），避免了Union的两次扫描+合并操作。如果担心重复数据，可以加DISTINCT（但只有在确实有重复时才加，因为DISTINCT也会带来额外开销）。
  示例：

  SELECT DISTINCT col1, col2, ... 
  FROM your_table 
  WHERE [原业务条件] OR a.UI = 1414
  

  提示：可以查看执行计划，如果SQL Server对OR条件生成了低效的执行计划，可能需要给[原业务条件]中的关键字段和a.UI创建复合索引，帮助优化器快速定位数据。

• 检查并优化索引
  不管用哪种替代方案，索引都是性能优化的核心：

  • 给a.UI字段创建非聚集索引，并且包含查询需要返回的所有列（覆盖索引），这样a.UI = 1414的查询可以直接从索引获取数据，不需要回表。
  • 确保原业务条件中的过滤字段有合适的索引，保证第一部分查询的性能不会拖后腿。
  • 更新表的统计信息：执行UPDATE STATISTICS your_table;，让SQL Server优化器能生成更合理的执行计划。

• 用条件分支处理特殊场景（仅当上述方案不适用时）
  如果原查询和a.UI=1414的查询逻辑差异较大（比如关联的表不同），可以考虑用CTE或者子查询结合条件判断，避免不必要的去重操作。比如：

  WITH base_data AS (
      SELECT col1, col2, ..., a.UI 
      FROM your_table 
      WHERE [原业务条件]
  )
  SELECT col1, col2, ... FROM base_data
  UNION ALL
  SELECT col1, col2, ... FROM your_table WHERE a.UI = 1414 AND NOT EXISTS (
      SELECT 1 FROM base_data WHERE base_data.UI = 1414
  )
  

  这个方案复杂度较高，只在前面的方案无法满足需求时考虑。

最后，记得查看执行计划对比优化前后的差异，重点关注扫描次数、排序操作的开销——这些正是Union查询变慢的主要原因。

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