不能。union all仅垂直拼接结果集且不保留原分组来源，需手动添加source标识列；所有子查询列名、数量、类型须严格一致；并排对比应使用full join而非union all。
UNION ALL 后不能直接用 GROUP BY 做跨组对比？
不能。UNION ALL 只是把结果集垂直拼起来，它不保留“原分组来源”信息——你得手动加一列标识，否则后续根本分不清哪行属于哪个分组。
常见错误现象：SELECT COUNT(*) FROM (...) UNION ALL (...) GROUP BY ... 报错或逻辑错乱，因为 GROUP BY 作用在合并后的整张临时表上，不是按原始分组维度。
- 必须在每个子查询里显式添加来源标记，比如
SELECT 'sales_2023' AS source, SUM(amount) AS total FROM sales WHERE year = 2023 - 所有子查询的列名、数量、类型要严格一致，否则
UNION ALL会静默截断或报类型不匹配（如 PostgreSQL 会报UNION types text and integer cannot be matched） - 别用
UNION代替UNION ALL：去重开销大，且你大概率并不需要去重——分组结果天然不重叠
怎么让两个分组聚合结果并排对比（比如同比）？
UNION ALL 是纵向堆叠，不是横向拼接。真要“并排”，得用 FULL JOIN 或子查询关联，而不是靠 UNION ALL。
使用场景：你想看「2023 销售额」和「2024 销售额」在同一行里对比，而不是上下两行。
- 正确做法是把两个聚合写成两个子查询，用
ON TRUE或带条件的FULL JOIN连接，例如：SELECT a.total AS total_2023, b.total AS total_2024 FROM (SELECT SUM(amount) AS total FROM sales WHERE year = 2023) a FULL JOIN (SELECT SUM(amount) AS total FROM sales WHERE year = 2024) b ON TRUE
- 如果坚持用
UNION ALL，只能先堆叠再用窗口函数或自连接“拉平”，但可读性和性能都差，还容易漏 NULL 处理 - 注意 NULL 安全：两个子查询可能一方无数据，
FULL JOIN能保全两边，而INNER JOIN会丢掉缺失年份的行
UNION ALL 合并聚合结果时，ORDER BY 和 LIMIT 怎么加？
只能在整个 UNION ALL 语句最外层加 ORDER BY 和 LIMIT，子查询里加会报错（除 PostgreSQL 允许子查询带 ORDER BY + LIMIT 配合 OFFSET，但意义有限）。
性能影响：如果只想要前 10 行，但每个子查询都扫全表再合并，最后才 LIMIT 10，效率极低。
- 优化办法：子查询各自先
LIMIT（如果业务允许），比如查“各渠道 TOP 5 商品销量”，就该在每个子查询里ORDER BY qty DESC LIMIT 5 -
ORDER BY列必须是输出列名或序号，不能是子查询里的别名（如SELECT x AS a FROM t UNION ALL SELECT y AS a FROM u ORDER BY a在某些数据库里不认a，得写ORDER BY 1） - MySQL 8.0+ 和 PostgreSQL 支持对
UNION ALL结果直接ORDER BY，但 SQLite 要求外层套一层SELECT *才能排序
为什么用 UNION ALL 对比分组结果后，SUM 或 COUNT 翻倍了？
典型原因是子查询没去重，或者误把明细表当聚合表用了——UNION ALL 不改变行数，只是拼接，所以如果子查询里漏了 GROUP BY 或写了 SELECT *，就会把明细行全堆进来，再在外面 SUM 就失真。
容易踩的坑：
- 子查询里写了
SELECT user_id, amount FROM orders（明细），然后UNION ALL后又GROUP BY user_id，这等于把两个时间段的订单明细混在一起算，不是“分组后对比”而是“合并后重聚” - 用了
DISTINCT但位置不对，比如SELECT DISTINCT SUM(x) FROM t没意义，SUM本身是聚合函数，DISTINCT应该放在里面：SUM(DISTINCT x) - 时间范围有重叠（比如都用了
BETWEEN '2023-01-01' AND '2024-12-31'），导致同一笔记录被两个子查询同时计入
CASE WHEN 在单个查询里分条件聚合。
