UNION 去重但性能差，UNION ALL 拼接快但需确保无重复；列数、顺序、类型必须严格一致，类型不匹配会报错；列名以首查询为准；排序和去重逻辑需显式控制，不可依赖隐式行为。
UNION 和 UNION ALL 都能合并多个查询结果，但选错一个，轻则查出重复数据、重则拖垮查询性能——尤其在百万级表上，UNION 可能比 UNION ALL 慢 3–5 倍。
列数、顺序和类型必须严格一致才能用 UNION / UNION ALL
两个 SELECT 语句不能一个选 3 列、一个选 4 列；也不能第一个是 id, name, created_at，第二个写成 name, id, status——列顺序错位会导致字段含义错乱（比如把时间当 ID 插入）。类型也要兼容：整数对整数、字符串对字符串，INT 和 VARCHAR 强转可能隐式失败或截断。
常见错误现象：ORA-01790: expression must have same datatype as corresponding expression（Oracle）或 ERROR: UNION types integer and text cannot be matched（PostgreSQL）。
- 别依赖数据库自动隐式转换，显式用
CAST(... AS ...)或COALESCE对齐类型 - 列名以第一个
SELECT为准，后续子查询的别名无效，想改列名得在最外层再包一层SELECT - 如果某子查询需要加
WHERE或ORDER BY，必须用括号包裹，例如：(SELECT ... FROM t1 WHERE x > 0) UNION (SELECT ... FROM t2 ORDER BY y)
UNION 自动去重，但代价是排序 + 去重计算
UNION 不是简单“合并后 dedup”，它实际执行三步：合并全部结果 → 按所有列排序 → 扫描相邻行去重。这意味着即使你只想要最新一条重复记录，UNION 也无法控制保留哪条——它只留一个，且不保证是哪个。
性能影响明显：当单个子查询返回 10 万行，合并后去重可能触发磁盘临时排序，响应从毫秒级升到秒级。
- 不要为了“看起来干净”盲目用
UNION，先确认业务是否真需要唯一性 - 如果数据源本身无重（如分表按时间切片），直接用
UNION ALL更安全 -
UNION的排序行为不可控，不能替代ORDER BY；最终结果排序必须显式写在外层
UNION ALL 是纯拼接，快但要自己管重复和顺序
UNION ALL 就是把结果集头尾相接，不做任何额外处理。它快，但也会把本该过滤掉的脏数据、测试数据、重复导入记录一起吐出来。
典型误用场景：用 UNION ALL 合并用户主表和备份表，结果同一用户出现两次，下游统计翻倍。
- 用前务必确认各子查询逻辑隔离（如不同业务线、不同日期分区、不同状态标识）
- 若需排序，必须在外层加
ORDER BY，子查询里的ORDER BY单独无效（除非配合LIMIT或窗口函数） - MySQL 8.0+、PostgreSQL 支持在
UNION ALL外层加WITH TIES或分页优化，但别指望它自动帮你 dedup
什么时候该用 UNION，什么时候死守 UNION ALL
核心判断就一条：你能否接受重复行？如果答案是“不能”，且无法从业务源头规避重复（比如合并员工表和外包表，ID 可能撞车但姓名相同），那只能用 UNION，并接受性能折损。
但如果重复是已知可忽略的（如日志表按天分表查询）、或重复本身就是有效信息（如操作流水多次提交），UNION ALL 是唯一合理选择。
- 别在
UNION上套DISTINCT——语法非法，UNION本身已含去重语义 - 嵌套太多
UNION（>5 层）容易触发优化器退化，考虑改用临时表或 CTE 预聚合 - 某些数据库（如 SQLite）对
UNION的排序策略较激进，小数据量看不出，一上生产环境就卡住，务必压测
真正难的不是语法，而是判断“这一行重复，到底算 bug 还是 feature”。很多线上问题，根源不在 SQL 写错，而在合并前没想清楚：你到底想看真实数据流，还是想看清洗后的视图。
