SQL如何高效合并两个结构相似的表：使用UNION ALL代替不必要的JOIN
想把两个结构相似的表合并起来，你首先想到的是不是JOIN？其实，在很多场景下，UNION ALL才是那个更直接、更高效的选择。关键在于，你得先搞清楚自己的目标：是要把数据“纵向堆叠”起来，还是要“横向关联”起来。前者是UNION ALL的战场，后者才是JOIN的领域。用错了工具，不仅逻辑别扭，性能也可能一落千丈。
UNION ALL 什么时候比 JOIN 更合适
答案其实很明确：当两个表的列结构完全一致（列数、数据类型、顺序都匹配），而你只是想简单地把它们上下拼在一起时，UNION ALL就是最合适的工具。这种需求在实际工作中并不少见，比如合并不同月份的日志分表（logs_202401 和 logs_202402）、汇总多租户的隔离数据，或者在ETL过程中归并来自不同来源的原始记录。
这里有个核心区别需要牢记：JOIN的本质是横向扩展，目的是增加列；而UNION ALL是纵向扩展，目的是增加行。如果硬要用JOIN去完成“堆叠”的任务，往往需要虚构一个连接条件（比如写ON 1=1），这本身就违背了JOIN的设计初衷，更糟糕的是，它极易引发笛卡尔积，导致结果集行数爆炸。
一个典型的反面教材：有人试图用LEFT JOIN去拼接两个没有业务关联的用户快照表，本想得到一个完整的用户列表，结果查询卡死，返回的行数远超预期。这完全是工具选错了方向。
为什么 UNION ALL 性能通常更高
性能优势来自于其简单直接的工作原理。UNION ALL不做去重，不进行排序，也不需要构建复杂的哈希表。它的工作流程就是顺序读取数据，然后直接追加输出。数据库引擎可以近乎流式地处理它，内存占用小，执行计划也非常干净。
我们不妨对比一下：
- 普通的
UNION（不带ALL）隐含着DISTINCT操作，会强制进行排序或哈希计算以去除重复行，这带来的IO和CPU开销是巨大的。 - 各种
JOIN操作则需要基于连接键构建索引或进行嵌套循环匹配，产生的中间结果集大小可能远超原始表的数据量。
当然，选择哪个操作符，语义正确是第一位的。如果你需要的是“不重复的全集”，那么UNION在语义上是正确的，但必须接受其性能代价。反之，如果业务场景本身允许甚至需要保留重复记录（例如审计日志要求记录每一次操作），那么UNION ALL就是唯一合理且高效的选择。
结构相似 ≠ 可以直接 UNION ALL
“结构相似”听起来简单，但魔鬼藏在细节里。它要求的不是列名相同，而是列的数量、数据类型以及顺序必须严格一致。否则，等待你的要么是明确的报错：ERROR: each UNION query must ha ve the same number of columns，要么是更隐蔽的隐式类型转换失败。
实践中，有这么几个要点能帮你避开坑：
- 显式指定列名，告别
*： 养成写SELECT id, name, created_at FROM t1的习惯，而不是用SELECT *。这能确保上下两部分查询的列是对齐的。 - 手动处理类型不一致： 如果
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，数据库优化器未必能聪明地将这个限制“下推”到每个分支，从而提前终止小表的扫描。在这种情况下，可能需要重新评估数据架构，考虑使用分区表或物化视图来从根本上优化查询模式。
