union自动去重原理是隐式执行distinct，逐列比对整行全等（含null视为相等），代价是需排序或哈希、建临时表，性能显著低于union all；要求各子查询列数、顺序、类型严格兼容，列名以首个select为准。
UNION 自动去重的原理和代价
UNION 会隐式执行 DISTINCT，把两个结果集合并后剔除完全重复的行。这不是“智能去重”，而是逐列比对所有字段值是否全等——只要某一行在两个子查询中出现两次（哪怕来自同一表），就只保留一次。
这意味着：如果两表结构相同但业务上允许部分重复（比如不同时间点采集的用户状态），用 UNION 反而会丢失数据；另外，去重需要临时排序或哈希，大数据量时性能明显低于 UNION ALL。
- 必须保证每个
SELECT的列数、顺序、数据类型兼容（如INT和VARCHAR混用可能隐式转换失败） - 列名以第一个
SELECT为准，后续子查询的别名无效 - 不能在单个子查询里用
ORDER BY，只能在整个 UNION 末尾加ORDER BY
列对齐出错：常见类型不匹配场景
比如想合并 users 表的 id, name, created_at 和 temp_users 表的 user_id, full_name, insert_time，直接写：
SELECT id, name, created_at FROM users UNION SELECT user_id, full_name, insert_time FROM temp_users
会失败——不是因为别名不同，而是因为 created_at 是 DATETIME，insert_time 是 TIMESTAMP，某些数据库（如 MySQL 5.7 严格模式）拒绝隐式转换。
- 显式用
CAST(insert_time AS DATETIME)对齐类型 - 补占位值：若
temp_users缺少status字段，用NULL AS status保持列数一致 - 字符串长度差异（如
VARCHAR(50)vsVARCHAR(100)）通常可接受，但TEXT和VARCHAR在部分引擎中会报错
什么时候该用 UNION ALL 而不是 UNION
当你确认两组数据天然无交集（例如：分表存储的订单数据按年拆分，orders_2023 和 orders_2024），或者你本就要保留重复（比如统计各渠道新增用户数，同一用户可能被多个渠道上报）——这时强制去重纯属浪费 CPU 和内存。
-
UNION ALL执行速度通常是UNION的 2–5 倍（取决于数据量和重复率） - PostgreSQL 中，
UNION默认走Unique + Sort计划，UNION ALL直接 Append - 如果后续还要
GROUP BY或WHERE过滤，先UNION ALL再聚合，往往比UNION后再过滤更高效
ORDER BY 和 LIMIT 必须放在最后
很多人试图这样写：
SELECT id, name FROM users ORDER BY name LIMIT 10 UNION SELECT id, name FROM guests ORDER BY name LIMIT 10
语法直接报错：ORDER BY 不被允许出现在 UNION 的中间子句里。数据库无法判断你是想分别取前 10 再合并，还是合并后取前 10。
- 正确做法：整个 UNION 包进子查询，或直接在末尾加
ORDER BY和LIMIT - 若真要“各自取 top N 再合并”，得用 CTE 或嵌套查询，例如：
(SELECT ... LIMIT 10) UNION ALL (SELECT ... LIMIT 10) - 注意：末尾的
ORDER BY作用于最终合并结果，不是按第一个子查询的列名排序，而是按输出列的位置（如ORDER BY 2表示按第二列）
最常被忽略的是类型对齐细节——开发时用小数据测不出问题，上线后某张表突然存了超长字符串或空时间戳，UNION 就开始静默截断或报错。动手前先 DESCRIBE 两张表，逐列核对类型和约束。
