union all在表结构一致且需纵向堆叠数据时比join更合适，因其不排序、不去重、低开销，避免笛卡尔积；需确保列数、类型、顺序严格匹配，并下推where、显式指定列名。
UNION ALL 什么时候比 JOIN 更合适
当两个表结构一致（列数、类型、顺序匹配），且目标是把数据“堆叠起来”而不是“按字段关联”，UNION ALL 就是更直接的选择。比如日志分表（logs_202401 和 logs_202402）、多租户隔离表、或ETL中不同来源的原始记录归并。
JOIN 的本质是横向扩展（增加列），而 UNION ALL 是纵向扩展（增加行）；强行用 JOIN 去“合并同类数据”，往往要虚构连接条件（比如加 ON 1=1），不仅逻辑别扭，还会触发笛卡尔积风险。
常见错误现象：用 LEFT JOIN 拼接两个无业务关联的用户快照表，结果行数爆炸，查询卡住，还查不出想要的“全部用户列表”。
为什么 UNION ALL 性能通常更高
UNION ALL 不去重、不排序、不建哈希表，就是顺序读取 + 追加输出。数据库引擎基本可以流式处理，内存占用低，执行计划干净。
相比之下：
-
UNION隐含DISTINCT，会强制排序或哈希去重，IO 和 CPU 开销陡增 -
JOIN需要构建连接键索引（即使没索引也要走嵌套循环），中间结果集可能远大于原始数据
注意：如果两张表都有主键且你只想要“不重复的全集”，UNION 是语义正确的，但得接受性能代价；若业务明确允许重复（例如审计日志本就该保留所有写入），UNION ALL 是唯一合理选择。
结构相似 ≠ 可以直接 UNION ALL
列名可以不同，但列数、数据类型、顺序必须严格一致。否则会报错：ERROR: each UNION query must have the same number of columns 或隐式转换失败。
实操建议：
- 显式写出列名，不要用 *：SELECT id, name, created_at FROM t1 UNION ALL SELECT id, name, created_at FROM t2
- 类型不一致时，手动转：比如 t1.status 是 INT，t2.status 是 VARCHAR，就得写 CAST(t2.status AS INT) 或统一转成文本
- 时间字段注意时区：timestamptz 和 timestamp 混用可能导致值偏移，不是报错而是逻辑错误
带 WHERE 或 ORDER BY 的 UNION ALL 怎么写才不踩坑
UNION ALL 整体不保证顺序，每个子查询里的 ORDER BY 单独生效也没意义（除非配合 LIMIT）。真要全局排序，必须把整个 UNION ALL 包进子查询或 CTE：
SELECT * FROM ( SELECT id, name, 't1' AS src FROM t1 WHERE status = 1 UNION ALL SELECT id, name, 't2' AS src FROM t2 WHERE status = 1 ) AS u ORDER BY id;
另外，WHERE 条件尽量下推到每个分支里——比如上面例子中分别过滤 status = 1，而不是在外部再过滤，能大幅减少扫描量。
真正容易被忽略的是：当表量级差异极大（比如一张百万行，一张十亿行），UNION ALL 的执行时间基本由大表决定，但如果你在外部加了 LIMIT 10，数据库未必能提前终止小表扫描——优化器不一定做“limit pushdown”。这时候得考虑是否改用分区表或物化视图。
