UNION自动去重并默认按第一列升序排序，UNION ALL仅拼接不处理重复；前者底层先拼接再建临时表排序去重，性能远低于后者，适用需保唯一性场景，后者适用于已知无重复或后续自行处理的场景。
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，也别依赖默认行为。