UNION 与 UNION ALL 的本质区别在于执行计划是否强制排序：UNION 必然触发排序去重，UNION ALL 直接拼接零开销；列数须严格相等，列名以首个 SELECT 为准，类型兼容性因数据库而异；ORDER BY 和 LIMIT 只能置于整个语句末尾。
UNION 和 UNION ALL 本质区别在哪
根本不在“要不要去重”，而在“执行计划是否强制排序”。UNION 内部会把两个结果集合并后走一次 DISTINCT（通常靠排序实现），UNION ALL 则直接拼接，零额外开销。
这意味着：即使两个子查询本身已无重复、且按相同字段排序，UNION 仍大概率触发临时排序；而 UNION ALL 永远不。
- 用
UNION却没去重需求 → 白耗 CPU 和内存，尤其数据量大时延迟明显 - 用
UNION ALL却忘了业务逻辑其实要唯一 → 结果多出重复行，下游统计崩掉 - 某些数据库（如 PostgreSQL）对
UNION的排序行为不可控，ORDER BY 必须放在最后，不能写在单个子句里
列名、类型、数量不一致时的报错表现
两个 SELECT 的列数必须严格相等，否则直接报错：ERROR: each UNION query must have the same number of columns。列名以第一个 SELECT 为准，后续子句的列名被忽略。
类型兼容性取决于数据库：MySQL 会隐式转换（比如把 INT 和 VARCHAR 都转成字符串比），PostgreSQL 更严格，要求类型一致或存在明确隐式转换路径。
- 常见翻车点：
SELECT id, name FROM t1 UNION SELECT name, id FROM t2→ 列顺序错位，id和name类型强行匹配，可能报错或值错乱 - 别名只在最终结果可见，子句中不能用别名参与计算：
SELECT a+1 AS x FROM t1 UNION SELECT x FROM t2→x在第二个SELECT中未定义，语法错误 - NULL 值参与
UNION去重时，所有 NULL 被视为相等，会被合并成一个
ORDER BY 和 LIMIT 怎么加才有效
ORDER BY 和 LIMIT 只能出现在整个 UNION 或 UNION ALL 语句末尾，不能作用于单个子查询（除非用括号包成子查询）。否则会报错：ERROR: ORDER BY in a union query must appear in the final query。
想对每个子集单独排序再合并？不行。必须先用子查询封装：(SELECT * FROM t1 ORDER BY c1 LIMIT 10) UNION ALL (SELECT * FROM t2 ORDER BY c1 LIMIT 10) —— 注意括号和 ORDER BY 在这里只是装饰，真正生效仍依赖外层是否再排序。
- 想取并集后的前 10 行：
SELECT ... UNION ALL SELECT ... ORDER BY x LIMIT 10 - 误写成
SELECT ... ORDER BY x LIMIT 10 UNION ALL SELECT ...→ 语法错误 - PostgreSQL 允许在子查询中用
ORDER BY+LIMIT，但仅用于控制子查询输出顺序，不影响UNION合并逻辑
性能差异在什么场景下最明显
当两个结果集都很大（比如各 50 万行）、且本身已无重复时，UNION 可能比 UNION ALL 慢 3–10 倍，主因是排序 + 去重阶段的磁盘临时表 IO。如果其中一结果集为空，优化器有时能跳过排序，但不可依赖。
小数据量（UNION。
- 日志归档合并、分表查询汇总、ETL 中间层拼接 → 几乎都该用
UNION ALL，去重交给上游或下游处理 - 权限校验需合并多个角色的菜单 ID，且不允许重复 → 必须用
UNION，但建议提前确认各角色菜单集本身无交集，否则排序成本白付 - EXPLAIN 看执行计划时，
UNION通常带Unique或Sort节点，UNION ALL就是纯Append
别指望数据库替你判断“要不要去重”——那是个业务逻辑问题，不是 SQL 语法问题。写之前想清楚：这俩结果集，天然就该有重复吗？如果有，留着还是干掉？干掉的话，是在这里干，还是在应用层干？
