UNION ALL + GROUP BY 比 UNION + GROUP BY 快，因其避免中间去重与排序，将去重逻辑交由 GROUP BY 一次性完成；UNION 先强制 DISTINCT 和隐式排序，触发两层 Using temporary，而 UNION ALL + GROUP BY 仅一层，执行计划更优、下推更可行。
UNION ALL + GROUP BY 为什么比 UNION + GROUP BY 快
因为 UNION 会在合并阶段强制做一次去重（等价于加了 DISTINCT 和隐式 ORDER BY），而 UNION ALL 只是流式拼接，把去重逻辑完全交给外层 GROUP BY 一次性完成。中间少了一次临时表 + 文件排序，执行计划更干净。
常见错误现象：SELECT id FROM t1 UNION SELECT id FROM t2 GROUP BY id 看似“先去重再分组”，实际会报错或被解释为两层操作：UNION 先建临时表去重，再对去重结果做 GROUP BY——等于白干一遍聚合。
-
UNION触发Using temporary+Using filesort（EXPLAIN 可见） -
UNION ALL + GROUP BY通常只触发一层Using temporary，且优化器更可能用哈希聚合 - 数据量越大，差距越明显：100 万行时，
UNION + GROUP BY可能比UNION ALL + GROUP BY慢 11 倍以上
必须用子查询包裹 UNION ALL 才能 GROUP BY
UNION ALL 本身不是单个查询主体，不能直接跟 GROUP BY。语法上必须用括号包成派生表，并显式加别名，否则报错。
正确写法：SELECT COUNT(*), status FROM (SELECT status FROM orders_2024 UNION ALL SELECT status FROM orders_2025) AS combined GROUP BY status
- 别名
AS combined不可省略，MySQL / PostgreSQL / SQL Server 全部强制要求 - 子查询里的
ORDER BY或LIMIT必须写在每个SELECT内部，外层不能出现 - 列名以第一个
SELECT为准，后续子查询的别名（如user_id AS id）只是语义提示，不改变输出列名
列对齐和类型兼容性必须手动处理
UNION ALL 对结构校验和 UNION 完全一致：列数、顺序、类型都得严格匹配，否则直接报错，不会自动补位或转换。
典型报错：ERROR 1222: The used SELECT statements have a different number of columns 或 MySQL 8.0+ 的严格模式下因类型不兼容中断执行。
- 缺列就用
CAST(NULL AS VARCHAR)或NULL::TEXT显式补位，别依赖隐式转换 - 加标识字段（如
'2024' AS source_year）方便后续按来源过滤或调试 - 如果某列在一张表是
INT NOT NULL，另一张是INT NULL，MySQL 8.0+ 严格模式下会报错，逼你提前确认业务含义
真正容易被忽略的是：你到底需不需要全局去重
很多场景下，UNION 看似“更安全”，实则掩盖了数据问题。比如两张日志表按时间分区，天然无交集，用 UNION 去重纯属冗余；又比如字段类型混用（VARCHAR 和 TEXT）导致排序规则不一致，UNION 隐式转换后分组结果不可靠，而 UNION ALL 会更早暴露类型冲突。
更关键的是：如果目标是统计汇总（如总订单数、平均金额），GROUP BY 本就要覆盖全部原始行，中间去重反而干扰计数逻辑——尤其是当重复行本就携带不同业务上下文（如不同状态、不同时间戳）时，UNION ALL 保留完整信息，才让外层聚合可控。
