union 和 UNION ALL 都用于合并多个 select 查询的结果集，但性能和语义差异显著——关键不在“怎么写”，而在“什么时候用对”。用错一个，可能让查询变慢几倍，甚至返回错误数据。
UNION 会去重 + 排序，代价高
UNION 实际执行时，数据库会自动对全部结果做 DISTINCT（去重）并隐式排序（多数引擎按字段顺序升序）。这意味着：即使你不需要排序，它也得排；即使数据天然不重复，它仍要扫描、哈希或排序去重。
- 若两个子查询结果本身无重复（比如查不同日期的订单、不同状态的用户），强行用 UNION 就是白耗 CPU 和内存
- 若字段含 TEXT、json 或大对象，去重开销指数级上升，可能触发磁盘临时表
- 没有 ORDER BY 时，UNION 后结果顺序不可靠——别依赖默认顺序
UNION ALL 是纯拼接，零额外开销
它不做任何去重或排序，只是把各查询结果逐行追加。只要列数、类型兼容（可隐式转换），就直接输出。
- 适合日志归档、分表汇总、多条件并行扫描等场景（如：查2023年各季度销售，每季度数据天然隔离）
- 配合外部 ORDER BY 使用更可控：“SELECT * FROM (q1 UNION ALL q2) t ORDER BY create_time DESC”
- 如果真需要去重，且数据量不大，可在外层套一层 DISTINCT，比 UNION 更透明、更易调优
类型兼容性比想象中严格
UNION/UNION ALL 要求各查询对应列的数据类型“兼容”，但具体规则因数据库而异：
- mysql 会尝试隐式转换（如 ‘1’ 和 1 可 union），但可能截断或报错（如 VARCHAR(10) 和 VARCHAR(5) union 时后者被截）
- postgresql 更严格，要求类型完全一致或存在明确转换函数，否则报错
- 建议显式 CAST：SELECT CAST(id AS BIGINT), name FROM t1 UNION ALL SELECT id, name FROM t2
替代方案：有时不该用 UNION
不是所有“合并结果”都该用 UNION。高频误用场景有：
- 同一张表不同 WHERE 条件？考虑 CASE WHEN + GROUP BY，一次扫描搞定
- 需要关联后合并？先 JOIN 再 UNION ALL，比多次 JOIN 后 UNION 快得多
- 分页需求强烈？UNION 后再 LIMIT OFFSET 效率极低，改用窗口函数或 ID 范围分片
不复杂但容易忽略：先确认数据是否天然不重复，再选 UNION ALL；需要去重时，评估是否真要全局去重，还是业务层可处理；类型问题宁可显式转换，别赌数据库的隐式规则。