你真的了解Oracle里那个UNION ALL是怎么回事吗，还是只是听说过而已？

开始）

你真的了解Oracle里那个UNION ALL是怎么回事吗，还是只是听说过而已？这个问题问得挺好，很多人可能确实只是知道个名字，觉得就是把两个查询结果“摞在一起”，但里面的门道可能还真没细琢磨过，今天咱们就掰开揉碎了讲讲，不整那些高大上的专业术语,就用大白话聊明白。

咱得从最基本的说起，UNION ALL在Oracle里，干的事儿确实很简单直接，想象一下，你有两筐水果（来源：Oracle官方文档关于集合操作的基本概念），一筐是苹果（来自第一个SELECT语句），另一筐是橘子（来自第二个SELECT语句），你现在想看看总共有多少水果，不在乎它们是啥，就直接把第二筐倒进第一筐里，这个“倒进去”的动作，基本上就是UNION ALL在做的事情，它不管三七二十一，就是把第二个查询的结果集，原封不动地接在第一个查询结果集的屁股后面，你第一个查询查出10行，第二个查出5行，用了UNION ALL之后，最终结果就是15行，哪怕这两筐水果里可能有一模一样的两个苹果（即重复数据），UNION ALL也会把它们都留下来,不会扔掉任何一个。

说到这儿，就得提一提它那个著名的“亲戚”——UNION了（来源：常见的SQL对比教程和数据库知识文章），UNION干的活儿跟UNION ALL很像，也是把两个结果集合并，但关键区别在于，UNION是个“强迫症”，它合并完之后，还得费劲巴拉地对所有数据进行一遍“查重”，把重复的行给删除掉，只保留唯一的一行，这就好比，你把两筐水果倒在一起后，还特意把长得一模一样的苹果挑出来，只留一个，其他的扔掉，这个“查重”的过程，在数据库里是需要耗费额外资源和时间的（比如排序、比较），一个非常重要的结论就来了：如果你能百分之百确定你要合并的两个结果集里没有重复数据，或者你根本就不在乎重复数据，希望保留所有记录，那么一定要用UNION ALL，而不是UNION。 因为UNION ALL少了那个昂贵的去重步骤，它的执行效率通常比UNION要高得多，在很多数据库优化建议里（来源：大量的SQL性能优化实践经验总结）,这都被列为一条基本原则。

那UNION ALL具体是怎么工作的呢？数据库引擎拿到你的SQL语句，看到UNION ALL，它会先分别执行那两个（或者多个）SELECT语句，你可以把它们想象成两个独立的生产线，各自生产出自己的产品（结果集），UNION ALL这个环节就像一个简单的传送带，把第二条生产线出来的产品，紧接着第一条生产线的产品排放好，直接输出给用户，它不会去检查产品是不是重复的，也不会重新给产品排序，这里有个常见的误区：很多人以为用了UNION ALL，最后的结果会按照某种顺序排列，其实不然，除非你最后显式地加上一个ORDER BY子句，否则结果集的顺序是不确定的（来源：数据库查询处理原理），数据库可能会按照它认为最方便的顺序输出，这个顺序可能跟第一个查询的顺序有关，也可能无关,你不能依赖这种默认的顺序。

接下来聊聊能用UNION ALL干点啥实际的事，场景其实非常多（来源：常见的业务场景分析），你有一个数据库，里面有两张表，一张是在职员工表，另一张是离职员工表，现在老板让你拉一个清单，要把所有曾经在公司待过的员工（包括在职和离职的）基本信息都列出来，这时候，你就可以从在职员工表里SELECT一遍，再从离职员工表里SELECT一遍，然后用UNION ALL把两个结果合起来，因为一个员工不可能同时既在职又离职，所以这两部分数据天然就是没有重复的，用UNION ALL又快又好。

再举个例子，比如你想做数据统计，有一个销售记录表，你想分别查看今年和去年的TOP10销售产品，然后把两个列表合并起来做一个综合分析，你可以先查询今年的TOP10，再查询去年的TOP10，然后用UNION ALL合并，这里即使某个产品两年都进入了TOP10，它也是两条有意义的记录（分别属于不同年份），你并不想去重，所以UNION ALL正合适。

使用UNION ALL也不是完全没规矩，有个硬性要求就是两个（或更多）SELECT语句查询出来的“列”必须匹配（来源：SQL语法规范），这指的是列的数量必须一样多，而且对应位置上的列的数据类型也必须是兼容的，比如说，第一个SELECT语句查了三列：员工ID（数字类型）、员工姓名（字符串类型）、入职日期（日期类型），那么第二个SELECT语句也必须查三列，并且第一列最好是数字类型，第二列是字符串类型，第三列是日期类型（或者能自动转换成日期类型的字符串等），你不能第一个查询选三列，第二个查询选四列，那数据库就懵了，会报错，也不能说第一个查询的第一列是数字，第二个查询的第一列是日期，这样类型对不上,也可能出错。

再深入一点，聊聊性能的事儿（来源：对数据库执行计划的解读经验），虽然我们前面说UNION ALL通常比UNION快，但它也并非永远是最优解，如果你合并的两个查询本身都非常复杂，涉及大表的扫描、多表连接、复杂的条件过滤，那么即使使用UNION ALL，数据库也需要分别执行这两个“大”查询，成本也不低，或许可以通过优化单个查询的逻辑，或者用其他SQL写法（比如CASE WHEN等条件判断）来避免使用UNION ALL，从而达到更好的性能，这需要具体问题具体分析，但无论如何，理解UNION ALL“不排序、不去重”这个核心特点,是进行正确选择和后续优化的基础。

回到最开始的问题。“了解”UNION ALL，不仅仅是知道它能合并数据，更重要的是清楚它和UNION的效率差异，明白它适用的场景（需要保留重复记录或已知无重复时），懂得它背后简单直接的工作原理（串联结果集），并且注意使用时列的数量和类型必须匹配的语法规则，下次再用到它的时候，你就能更有底气了，而不是仅仅“听说过而已”。 结束）