能，但必须保证各子查询列数、顺序和数据类型兼容，并用NULL补位、source标识区分来源；ORDER BY和LIMIT仅能出现在最后，UNION ALL性能优于UNION。
UNION ALL 能不能直接合并 GROUP BY 的结果？
能，但必须保证每个 SELECT 子句的列数、顺序和数据类型兼容。很多人卡在这一步，不是语法错，而是 SELECT 列不一致导致报错或隐式转换出问题。
常见错误现象：ERROR: each UNION query must have the same number of columns 或数值被截断、日期变字符串。
- 所有子查询的
SELECT列数必须严格相等 - 同位置列尽量用相同类型（比如都用
INT，别一个INT一个VARCHAR） - 列名以第一个子查询为准，后续子查询的列名会被忽略——别指望靠第二个子查询起别名来统一字段名
怎么让不同维度的 GROUP BY 结果对齐成同一张宽表？
UNION ALL 本身是垂直拼接（追加行），不是横向合并（拼列）。想把「按部门统计」和「按城市统计」的结果塞进一张表里，得靠补占位符+统一字段语义。
使用场景：报表需要在一个结果集里同时展示「各部门销售额」和「各城市销售额」，但又不想写两个独立查询再用应用层拼。
- 用
NULL或默认值填充缺失维度（如部门汇总时，城市列填NULL） - 加一个标识字段说明来源，比如
'by_dept'和'by_city'，否则根本分不清哪行是哪类聚合 - 注意
GROUP BY后的聚合函数要和补位列配合，比如SUM(sales)可以，但AVG(sales)在混入NULL行后可能影响整体解读
示例：
SELECT 'by_dept' AS source, dept AS group_key, NULL::TEXT AS city, SUM(sales) AS total FROM orders GROUP BY dept UNION ALL SELECT 'by_city', NULL::TEXT, city, SUM(sales) FROM orders GROUP BY city;
ORDER BY 和 LIMIT 放在哪？为什么不能每个子句都写？
整个 UNION ALL 结果集只允许一个 ORDER BY 和一个 LIMIT，且必须放在最后。写在某个子查询末尾会直接报错。
性能影响：如果先 ORDER BY 再 UNION ALL，数据库没法下推排序，可能多做一次全量排序；反过来，把 ORDER BY 放最后，引擎通常能优化合并后的排序逻辑。
- 想对每个分组结果单独排序？不行，得用子查询套一层，或者改用窗口函数
-
LIMIT 10是对全部拼接后的结果取前 10 行，不是每个子查询各取 10 行 - 如果真需要“每组 top N”，
UNION ALL不是合适工具，该用ROW_NUMBER() OVER (PARTITION BY ...)
UNION ALL vs UNION：什么时候必须用 ALL？
只要不关心重复行，一律用 UNION ALL。它不查重、不排序，性能通常比 UNION 高 2–5 倍，尤其在大数据量聚合后拼接时差异明显。
容易踩的坑：有人以为 UNION 更“安全”，其实只要确认各子查询之间天然无重复（比如分组维度完全不同），UNION ALL 就更可靠——UNION 的去重逻辑可能因类型隐式转换意外吞掉本该保留的行。
- 检查是否真有跨子查询的重复：比如两个
GROUP BY都包含id = 1的情况？一般不会，除非设计混乱 - 若某子查询内部可能有重复（比如没写
GROUP BY却用了聚合函数），那是查询逻辑问题，不是UNION能救的 - MySQL 8.0+、PostgreSQL、SQL Server 都支持，但老版本 SQLite 对子查询中
GROUP BY+UNION ALL的解析偶尔抽风，建议加括号明确作用域
复杂点在于字段对齐和语义一致性，而不是语法本身。对不上列、没加 source 标识、乱用 ORDER BY，这三处出问题的概率远高于写错 UNION ALL 这几个字。
