UNION 会自动去重+排序，UNION ALL 只是拼接
这是最核心的区别：如果你执行
SELECT name FROM t1 UNION SELECT name FROM t2，MySQL 会把两个结果合并后，用类似
DISTINCT的方式筛掉重复行，并**默认按第一列升序排序**；而
UNION ALL就是“原样倒进去、不检查、不整理”，哪怕两表完全一样，结果里也会出现两遍相同记录。
常见错误现象：
用UNION合并日志表时，发现时间顺序乱了——其实是它悄悄给你排了序（按第一列，不是按时间字段） 用
UNION ALL查出大量重复数据，误以为 SQL 写错了，其实是业务本就允许/存在重复 没加
ORDER BY却看到有序结果，其实是
UNION的隐式排序在起作用
UNION 去重不是靠哈希，而是靠临时表 + 排序
MySQL 并不直接对两组结果做哈希比对去重。它的实际执行逻辑更接近：
SELECT DISTINCT * FROM ( SELECT * FROM t1 UNION ALL SELECT * FROM t2 ) AS combined
也就是说，
UNION底层先走一遍
UNION ALL拼出全量中间集，再建临时表、排序、逐行比较去重。这也是为什么
EXPLAIN看到
Using temporary; Using filesort—— 它真正在磁盘或内存里干了排序和去重的活。
性能影响很实在：
数据量过 10 万行，UNION耗时通常是
UNION ALL的 7–11 倍（实测数据见知识库） 如果字段没索引，排序阶段容易触发磁盘临时表（
tmp_table_size不够时）
UNION会破坏原始查询的索引优势，比如
ORDER BY id在子查询里写了，外层
UNION仍可能重排
什么时候必须用 UNION？什么时候死磕 UNION ALL？
别凭感觉选，看场景和数据特征：
✅ 必须用
UNION的情况： 多源客户表合并（CRM + ERP + 导入Excel），ID 或手机号可能重复，需保唯一性 统计口径不同但维度要统一（如
SELECT 'daily', cnt FROM d1 UNION SELECT 'weekly', cnt FROM w1），值本身可能撞车，得去重防歧义
✅ 优先用
UNION ALL的情况： 分表/分库日志查询：
SELECT * FROM log_202401 UNION ALL SELECT * FROM log_202402，天然按时间分片，无重复 CTE 中间聚合前拼接：
WITH raw AS (SELECT id FROM a UNION ALL SELECT id FROM b) SELECT id, COUNT(*) ...，后续自己控制去重逻辑 明确知道两结果集主键/联合唯一（如
user_id来自不同业务库，全局唯一）
ORDER BY 和列名对齐是硬约束，不是可选项
无论用哪个，都必须保证：所有
SELECT子句返回的列数、类型兼容性、顺序一致。否则直接报错：
ERROR 1222 (21000): The used SELECT statements have a different number of columns
另外，
ORDER BY只能写在最后一条
SELECT之后，且只能引用最终结果集的列名或位置（如
ORDER BY 1），不能在每个子句里单独写。
容易被忽略的一点：如果某列是
TEXT或
JSON类型，
UNION去重时可能因长度截断或 collation 差异导致“看似相同实则不同”，造成去重失效——这时宁可显式转成
SUBSTR(col, 1, 1000)再 union，也别依赖默认行为。
