union用于合并多个select结果集，要求列数相同且数据类型兼容，union会自动去重，而union all保留所有行包括重复行；2. 使用union all性能更高，适用于无需去重或数据本身无重复的场景；3. 列顺序必须一致，结果集列名以第一个select为准；4. 数据类型不兼容时应使用cast或convert显式转换；5. order by和limit/top必须置于整个union语句末尾，若需对子查询单独排序或限制，应将其封装为子查询并在内部应用order by和limit/top；6. null值在union去重中被视为相等。最终答案是：使用union或union all时需确保列数、顺序一致，类型兼容，合理选择去重方式，并正确放置order by和limit/top以控制最终结果排序和数量。
SQL中的
UNION
操作，简单来说，就是把两个或多个
SELECT
查询的结果集合并成一个单一的结果集。它就像是把几张表格的数据垂直地堆叠起来，但有个前提：这些表格的列数得一样，而且对应列的数据类型也得兼容。默认情况下，
UNION
会帮你去除重复的行，如果你想保留所有行，包括重复的，那就要用
UNION ALL
。
解决方案
要使用
UNION
或
UNION ALL
合并查询结果，基本语法非常直观：
SELECT column1, column2, ... FROM table1 WHERE condition1 UNION [ALL] SELECT column1, column2, ... FROM table2 WHERE condition2;
这里的关键点在于：
- 列的数量和顺序必须一致： 每个
SELECT
语句中选择的列的数量必须相同，并且它们的逻辑顺序也应该保持一致。比如，第一个查询选择了
姓名, 年龄
，第二个查询也必须选择
姓名, 年龄
，而不是
年龄, 姓名
。
- 数据类型兼容： 对应列的数据类型需要兼容。例如，如果你在第一个查询中选择了
VARCHAR
类型的列，那么在第二个查询的对应位置也应该是一个
VARCHAR
或可以隐式转换为
VARCHAR
的类型。数据库通常会尝试进行隐式转换，但为了稳妥和避免意外，如果类型差异较大，最好手动使用
CAST()
或
CONVERT()
进行显式转换。
- 最终结果集的列名： 合并后的结果集的列名通常会沿用第一个
SELECT
语句中定义的列名。
举个例子，假设我们有两个表，
employees_hr
记录了正式员工信息，
contractors_project
记录了项目外包人员信息，我们想把他们的姓名和联系方式合并起来：
-- 合并正式员工和外包人员的姓名和邮箱，并去除重复的邮箱地址 SELECT name, email FROM employees_hr WHERE status = 'active' UNION SELECT contact_name, contact_email FROM contractors_project WHERE project_status = 'ongoing'; -- 如果我们想保留所有记录，包括可能重复的邮箱地址，比如一个人既是正式员工又参与了外包项目 SELECT name, email FROM employees_hr WHERE status = 'active' UNION ALL SELECT contact_name, contact_email FROM contractors_project WHERE project_status = 'ongoing';
UNION 和 UNION ALL 有什么区别？什么时候用 UNION ALL 更好？
这可能是
UNION
操作中最常被问到的问题了。说白了，它们的核心差异就在于“去重”二字。
UNION
（不带
ALL
）会像一个严格的守门员，它会检查所有合并后的行，并确保每一行都是独一无二的。如果发现有两行的数据内容完全相同，它就只保留其中一行。这个去重过程通常需要数据库进行额外的排序和比较操作，所以，它会消耗更多的计算资源和时间。
而
UNION ALL
则是个大方的收集者，它会把所有符合条件的行照单全收，哪怕它们是完全相同的重复行。它不会进行任何去重操作，直接将所有查询结果堆叠起来。
什么时候用
UNION ALL
更好？
在我看来，
UNION ALL
在绝大多数情况下都是更优的选择，尤其是在处理大数据量时。原因很简单：
- 性能优势： 因为
UNION ALL
省去了去重这一步，它的执行速度通常比
UNION
快得多。在处理数百万甚至上亿行数据时，这个性能差异会非常显著。
- 明确的数据意图： 很多时候，我们合并数据就是为了获取所有相关的记录，重复本身可能就是一种有效的信息（比如，一个用户在不同时间段购买了同一件商品，你希望看到两次购买记录）。如果你的业务逻辑允许重复，或者你确定源数据中不会有你不需要的重复，那直接用
UNION ALL
，既高效又准确。
- 避免不必要的去重开销： 比如，你合并来自不同分店的销售记录，每条记录都有唯一的订单ID。虽然订单ID不同，但如果订单详情（商品、价格、日期）可能相同，
UNION
仍然会尝试去重所有列。如果你只想简单地把所有销售记录汇总，
UNION ALL
就足够了，而且效率更高。
什么时候必须用
UNION
？
只有当你明确需要一个完全不包含重复行的结果集时，才应该使用
UNION
。例如，你想获取所有参与过某个活动的用户ID列表，且每个用户ID只出现一次。在这种情况下，去重是你的核心需求，性能上的微小牺牲是值得的。但即便如此，我个人也更倾向于先用
UNION ALL
，然后在外层再加一个
DISTINCT
，这样能更清晰地表达意图，并且在某些数据库优化器下，性能可能反而更好，因为它给了优化器更多的选择空间。
使用 UNION 合并查询结果时需要注意哪些常见问题？
在使用
UNION
或
UNION ALL
时，确实有一些常见的“坑”和需要注意的地方，稍不留神就可能导致错误或者得到不符合预期的结果。
-
列数不匹配的错误： 这是最常见的错误之一。如果你在第一个
SELECT
中选择了3列，而在第二个
SELECT
中只选择了2列或4列，数据库会立即报错，类似“The number of columns in the UNION statement does not match.”。这个错误很直接，也容易排查。但有时候，如果列数很多，眼睛可能会看花，所以最好是数清楚。
-
数据类型不兼容的隐患： 即使列数匹配，如果对应列的数据类型不兼容，也可能出问题。比如，你把一个
VARCHAR
列和
INT
列合并，数据库可能会尝试进行隐式转换。如果转换失败（例如，
VARCHAR
列里有非数字字符），就会报错。即使转换成功，也可能导致数据丢失精度（比如把浮点数转成整数）或者结果不符合预期（比如数字被当成字符串排序）。我的建议是，如果遇到这种情况，显式转换是最佳实践。用
CAST(column AS desired_type)
来确保数据类型的一致性。
-- 错误示例：尝试合并字符串和数字 SELECT 'Item A' AS product_name, 100 AS price UNION ALL SELECT 123 AS product_id, 'Expensive' AS status; -- 这里的列类型不匹配，会报错或导致奇怪的转换 -- 正确做法：显式转换以确保兼容性 SELECT product_name, CAST(price AS VARCHAR(50)) AS info FROM products_table UNION ALL SELECT product_id, product_description FROM old_products_table;
-
列顺序的重要性：
UNION
操作是基于列的位置进行合并的，而不是基于列名。这意味着，如果你第一个查询是
SELECT Name, Age
，第二个查询是
SELECT Age, Name
，那么最终结果的
Age
列会包含第二个查询中的
Name
数据，而
Name
列会包含
Age
数据，这显然不是你想要的。务必确保每个
SELECT
语句中的列顺序与你期望的最终结果集的顺序一致。
-
性能考量，特别是对于
UNION
： 当处理非常大的数据集时，
UNION
的去重操作会带来显著的性能开销。数据库需要将所有结果集加载到内存中，进行排序，然后扫描以移除重复项。这可能导致高CPU和内存使用，甚至磁盘溢出。如果你的数据集非常庞大，并且你真的需要去重，考虑是否有其他更高效的去重策略，比如在源头就进行筛选，或者使用更优化的索引。如果不需要去重，毫不犹豫地选择
UNION ALL
。
-
NULL值的处理： 在
UNION
进行去重时，
NULL
值通常被认为是相等的。也就是说，如果两行除了都包含
NULL
值外，其他所有列都相同，它们会被认为是重复的。这与
WHERE
子句中
NULL
不等于
NULL
的行为是不同的，需要留意。
如何在 UNION 查询中使用 ORDER BY 和 LIMIT/TOP？
在
UNION
查询中使用
ORDER BY
和
LIMIT
/
TOP
（或
FETCH FIRST
等）时，它们的作用范围和位置非常关键，因为它们总是应用于整个合并后的最终结果集。
-
ORDER BY
的位置和作用：
ORDER BY
子句必须放在整个
UNION
语句的最后。它会根据指定的列对合并后的所有行进行排序。你不能在单个
SELECT
语句内部使用
ORDER BY
，除非那个
SELECT
语句被包裹在一个子查询中。
-- 错误示例：ORDER BY不能放在中间 SELECT name, email FROM employees_hr ORDER BY name -- 错误！ UNION ALL SELECT contact_name, contact_email FROM contractors_project; -- 正确示例：ORDER BY放在整个UNION的最后 SELECT name, email FROM employees_hr UNION ALL SELECT contact_name, contact_email FROM contractors_project ORDER BY name ASC, email DESC; -- 这里的name和email是第一个SELECT语句中的列名
你可以使用第一个
SELECT
语句中的列名来引用，也可以使用列的序号（例如
ORDER BY 1, 2
表示按第一列和第二列排序）。
-
LIMIT
/
TOP
（或
FETCH FIRST
）的位置和作用： 和
ORDER BY
类似，
LIMIT
（MySQL, PostgreSQL）或
TOP
（SQL Server）/
FETCH FIRST
（Oracle, SQL:2008标准）子句也必须放在整个
UNION
语句的最后，并且通常是在
ORDER BY
之后。它们用于限制最终合并结果集的行数。
-- 获取合并后结果的前10条记录，并按姓名排序 SELECT name, email FROM employees_hr UNION ALL SELECT contact_name, contact_email FROM contractors_project ORDER BY name ASC LIMIT 10; -- MySQL/PostgreSQL -- SQL Server 示例 SELECT TOP 10 * FROM ( SELECT name, email FROM employees_hr UNION ALL SELECT contact_name, contact_email FROM contractors_project ) AS combined_data ORDER BY name ASC;
-
如果需要对每个子查询单独排序或限制： 这是一个常见的需求，比如你想从A部门取出销售额最高的5名员工，再从B部门取出销售额最高的5名员工，然后将这两组人合并。在这种情况下，你必须将每个
SELECT
语句包装成一个子查询，并在子查询内部进行
ORDER BY
和
LIMIT
/
TOP
操作。
-- 示例：获取两个部门各自销售额最高的3名员工，然后合并 SELECT employee_name, sales_amount FROM ( SELECT name AS employee_name, sales AS sales_amount FROM sales_department_a ORDER BY sales DESC LIMIT 3 ) AS top_sales_a UNION ALL SELECT employee_name, sales_amount FROM ( SELECT name AS employee_name, sales AS sales_amount FROM sales_department_b ORDER BY sales DESC LIMIT 3 ) AS top_sales_b ORDER BY sales_amount DESC; -- 最终再对合并结果进行排序
这种方式确保了每个部门的“前N名”是独立计算的，然后才被合并。如果直接在外部
UNION
后加
LIMIT
，那它会从所有员工中找出销售额最高的N名，而不是每个部门各N名。理解这一点对于编写精确的SQL查询至关重要。
评论（已关闭）
评论已关闭