SQL中使用UNION ALL合并同结构子查询的正确性及优化咨询

嘿，先给你吃个定心丸：你用UNION ALL的方式完全正确！因为你要的是整合所有年份的原始数据，而且没有提到需要去重，UNION ALL会直接拼接结果集，不会像UNION那样额外做去重操作，效率反而更高——这部分的选择是没问题的。

不过你提到的重复代码和耗时问题确实有优化空间，我给你两个方向的建议：

1. 消除重复代码：合并重复的子查询逻辑 #

看起来每个yearXX的CTE逻辑应该是高度相似的，只是年份参数不同？如果是这样，完全不用单独定义每个年份的CTE，我们可以把年份作为过滤条件，用一个通用查询来覆盖所有目标年份：

示例1：基础查询场景 #

如果你的子查询只是简单过滤年份，比如：

-- 你原来的year15可能是这样的
year15 AS (
    SELECT 2015 AS year, week, value 
    FROM your_table 
    WHERE year = 2015
)

那直接合并成一个查询就好：

SELECT year, week, value
FROM your_table
WHERE year IN (2015, 2016, 2017)

示例2：复杂计算/聚合场景 #

如果每个年份的子查询有复杂的计算（比如聚合、关联），但逻辑一致，那可以用年份列表CTE来复用逻辑：

WITH target_years AS (
    SELECT 2015 AS target_year UNION ALL 
    SELECT 2016 UNION ALL 
    SELECT 2017
),
unified_data AS (
    SELECT 
        ty.target_year AS year,
        t.week,
        -- 这里放你原来每个子查询里的value计算逻辑，比如SUM/AVG等
        SUM(t.some_column) AS value
    FROM your_base_table t
    JOIN target_years ty ON t.year = ty.target_year
    -- 原来的WHERE过滤、GROUP BY分组等通用逻辑
    WHERE t.some_condition = 'xxx'
    GROUP BY ty.target_year, t.week
)
SELECT year, week, value FROM unified_data

2. 优化查询性能：减少重复计算与扫描 #

耗时超出预期的原因，大概率是重复的CTE让数据库多次执行相同逻辑的查询（比如多次扫描同一张表），你可以从这几点入手优化：

• 检查索引：确保你的基础表在year、week字段上有合适的索引，如果有聚合操作，复合索引（比如(year, week, some_column)）能让数据库直接从索引获取数据，避免全表扫描。
• 避免重复关联：如果原来的子查询涉及多表关联，合并后只需要关联一次，而不是每个年份都关联一次，能大幅减少IO开销。
• 简化计算逻辑：检查子查询里有没有不必要的计算步骤，比如重复的函数调用、多余的字段，把这些简化后也能提升速度。

总的来说，UNION ALL本身是正确的选择，但重复的CTE写法既不优雅，又会让数据库做重复的工作。通过合并重复逻辑+优化索引，应该能同时解决代码冗余和性能问题。

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