union会隐式去重并排序，性能差；union all仅拼接，无去重排序开销，速度快十倍。语义不同：需唯一结果用union，要全部行且求快用union all。
UNION 和 UNION ALL 不是“高级写法”，而是语义与性能完全不同的两个操作：要唯一结果就用 UNION，要全部行且快就用 UNION ALL。选错一个，轻则结果错，重则查询变慢十倍。
UNION 会隐式排序并强制去重，不是“自动优化”
执行 UNION 时，MySQL 实际做了三件事：合并 → 去重（基于所有列值完全一致）→ 按第一列升序排序。哪怕你没写 ORDER BY，结果顺序也大概率不是你两个子查询的原始顺序。
- 去重依赖临时内存或磁盘排序；当任一结果集超过
sort_buffer_size，就会落盘，性能断崖下跌 - 尾部空格、collation 差异（比如
utf8mb4_0900_as_csvsutf8mb4_general_ci）会导致“看起来一样却判为不同”，去重失效 - 如果业务只要“逻辑去重”（比如只按
id去重，不管name是否有空格），UNION无法满足——它必须全列一致才算重复
UNION ALL 不校验类型兼容性，但列数和顺序是硬约束
UNION ALL 只做物理拼接，不比较、不排序、不建临时表，所以快。但它对结构要求更“死板”：
- 列数必须严格相等，少一列或多一列直接报错：
ERROR 1222 (21000): The used SELECT statements have a different number of columns - 对应位置列类型需“可隐式转换”：比如
TINYINT和INT可以，但DATE和VARCHAR(10)通常不行，会报ERROR 1267 (HY000): Illegal mix of collations或类型冲突 - 别名只认第一个
SELECT的：写SELECT id AS user_id FROM t1 UNION ALL SELECT id AS order_id FROM t2，最终列名仍是user_id，后面那个order_id被忽略
想整体排序？必须包子查询，不能只在某个分支加 ORDER BY
你不能这样写：(SELECT * FROM t1 ORDER BY created_at DESC LIMIT 5) UNION ALL (SELECT * FROM t2 ORDER BY updated_at DESC LIMIT 5) —— 这里的两个 ORDER BY 只作用于各自子查询，拼完后整体仍是无序的。
正确做法是把整个 UNION ALL 当作内层结果，再套一层：
SELECT * FROM ( SELECT id, name, 'user' AS src FROM users UNION ALL SELECT id, title, 'post' AS src FROM posts ) AS merged ORDER BY id DESC;
- 注意：外层
ORDER BY才决定最终顺序；内层ORDER BY必须配合LIMIT才有效（否则被优化器忽略） - 如果只是想取每个来源的最新 5 条再合并，上面写法是对的；但如果想“合并后取全局最新 5 条”，就得先拼全再
ORDER BY ... LIMIT 5
什么时候非用 UNION 不可？只有两种真实场景
别被“去重听起来更干净”误导。真正绕不开 UNION 的情况极少：
- 下游系统硬性依赖结果唯一性，比如前端分页缓存了第 2 页数据，换
UNION ALL后因重复行导致总行数变化，分页错乱 - 业务语义明确要求“所有出现过的 ID 只算一次”，例如统计“在订单表或购物车表中出现过的用户 ID 集合”，且这两个表之间没有主键关联，无法用
DISTINCT+JOIN替代
其他所谓“避免脏数据”“看起来整洁”都不是技术理由——那是应用层该处理的事。MySQL 层面，能用 UNION ALL 就别碰 UNION，尤其在线上高并发查询里，多一次去重可能就是几百毫秒延迟。
