union和union all的核心区别在于去重：union自动去重并默认排序，union all直接拼接、保留所有行（含重复），因此性能更高；二者均要求列数一致、类型兼容，且order by仅能作用于整个结果集。

UNION 和 UNION ALL 的核心区别在哪

根本区别在于去重逻辑：UNION 会自动去除重复行，等价于 UNION ALL + DISTINCT；UNION ALL 完全不检查重复，直接拼接。这意味着 UNION ALL 性能通常更高，尤其在大数据量或无重复预期的场景下。

常见错误现象：用 UNION 合并两个明显无重复的结果集（比如不同状态的订单），却没意识到数据库多做了排序和去重，拖慢查询；反过来，该去重时用了 UNION ALL，导致最终结果出现意外重复。

• 列数必须一致，否则报错 ORA-01789（Oracle）或 1222（MySQL）
• 对应列的数据类型需兼容，否则触发隐式转换失败（如 MySQL 中 VARCHAR 与 INT 混合）
• 列名以第一个子查询为准，后续子查询的别名不会生效

列对齐和类型匹配的实际处理方式

数据库按位置而非名称匹配列，所以必须保证每个 SELECT 子句中列的顺序、数量、类型可兼容。例如，不能让第一个查询返回 id, name，第二个返回 name, id —— 即使字段相同，顺序错位就会导致语义错误。

类型不一致时，各数据库策略不同：PostgreSQL 严格报错；MySQL 尝试转成更高精度类型（如把 TINYINT 和 INT 都转为 INT）；SQL Server 依据数据类型优先级隐式转换。

• 显式用 CAST 或 CONVERT 统一关键列类型，比如 CAST(created_at AS DATE)
• 用 NULL 占位补列，如第一个查询有 3 列，第二个只有 2 列，就写 SELECT a, b, NULL AS c
• 避免依赖隐式转换，特别是涉及字符串和数字混合时（如 '123' 和 123 在某些引擎中比较行为不一致）

ORDER BY 和 LIMIT 只能作用于整个 UNION 结果

ORDER BY 不能写在单个子查询末尾，否则语法报错（如 ERROR 1221）。它只能出现在整个 UNION / UNION ALL 语句最后，且排序依据的是第一个子查询的列名或位置。

同理，LIMIT（或 TOP、FETCH）也只对外层有效。想对某个子查询单独限制？必须用派生表（子查询套一层）。

• 正确写法：(SELECT id FROM t1) UNION ALL (SELECT id FROM t2) ORDER BY id DESC LIMIT 10
• 错误写法：SELECT id FROM t1 ORDER BY id LIMIT 5 UNION ALL SELECT id FROM t2
• 若需分别截断再合并，写成：(SELECT id FROM t1 ORDER BY updated_at DESC LIMIT 5) UNION ALL (SELECT id FROM t2 ORDER BY created_at DESC LIMIT 5)

性能差异在什么情况下真正显著

当任一子查询返回上万行、且存在较多潜在重复时，UNION 的去重开销会明显暴露：它需要临时排序或哈希表，内存/磁盘压力增大；而 UNION ALL 几乎是流式拼接。

但要注意：如果上层业务逻辑本就要求唯一性，强行用 UNION ALL + 应用层去重，反而可能引入一致性风险（比如分页时两次请求结果不一致）。

• 监控执行计划：关注是否出现 Unique（PostgreSQL）、Using temporary; Using filesort（MySQL）等字样
• 测试数据量级接近生产时再对比耗时，小数据下差异常可忽略
• 某些场景下，UNION 反而更快——比如两个子查询本身已排好序且结果集极小，去重成本低于额外的 ALL 语义校验开销（极少，但存在）

真正容易被忽略的是列顺序和 NULL 处理：两个子查询中同一位置的列，一个允许 NULL、一个定义为 NOT NULL，某些数据库会静默改变结果的可空性，影响后续 JOIN 或应用映射。