SQL中的UNION操作是什么？合并查询结果的正确方法（查询结果.合并.正确.操作.方法...）

wufei123 发布于 2025-09-11 阅读（1）
UNION操作用于合并多个SELECT结果集，要求列数、顺序一致且数据类型兼容，UNION自动去重而UNION ALL保留重复行，优先使用UNION ALL以提升性能，列名由第一个SELECT决定，ORDER BY和LIMIT应置于最后，避免列不匹配和类型隐式转换问题，结合CAST、显式列名和括号提高可靠性与可读性。

sql中的union操作是什么？合并查询结果的正确方法

SQL中的UNION操作，简单来说，就是将两个或更多SELECT语句的结果集合并成一个单一的结果集。它主要用于当你需要从多个结构相似的表中，或者从同一个表的不同查询中，提取并整合数据时，提供了一种简洁而强大的方式。在我看来，它就像是数据世界的“拼接艺术家”，能把零散的信息汇聚成一个整体，方便我们统一分析和展示。

SQL中的UNION操作，其核心思想就是“行合并”。当你手头有两份或多份数据清单，它们的内容结构（列的数量和类型）大体一致，但数据来源不同，或者你只是想把它们“堆叠”起来看时，UNION就派上用场了。

它的基本语法非常直观：

SELECT column1, column2, ...
FROM table1
WHERE condition1
UNION [ALL]
SELECT column1, column2, ...
FROM table2
WHERE condition2;

这里有几个关键点，也是我个人在使用时最常思考和检查的地方：

  1. 列的数量和顺序必须一致：这是硬性要求。第一个SELECT语句选择了多少列，第二个（以及后续所有）SELECT语句就必须选择同样数量的列。而且，这些列的顺序也应该对应，这样数据合并后才不会“错位”。
  2. 数据类型兼容：虽然不要求数据类型完全相同，但它们必须是兼容的。比如，你不能把一个文本列和日期列直接UNION起来，这在逻辑上就说不通。数据库系统会尝试进行隐式转换，但最好还是确保类型接近或一致，避免潜在的错误或意外结果。
  3. 结果集的列名：最终结果集的列名通常由第一个SELECT语句的列名决定。这一点在使用别名时尤其需要注意，后续SELECT语句中的别名会被忽略。

举个例子，假设我们有一个

employees
表和一个
contractors
表，它们都有
id
, 
name
, 
email
这些列，现在我想看所有员工和承包商的联系方式：
SELECT id, name, email
FROM employees
WHERE status = 'active'
UNION
SELECT id, name, email
FROM contractors
WHERE end_date IS NULL;

这样，我就能得到一个包含所有活跃员工和当前承包商的统一列表了。UNION默认会移除重复的行，如果你想保留所有行，包括重复的，那就需要用到

UNION ALL
。 UNION 和 UNION ALL 有何不同？何时选择哪种操作？

UNION和UNION ALL之间的差异，说白了，就在于对“重复数据”的处理方式上。理解这一点，对于优化查询性能和确保数据准确性至关重要。

UNION (默认行为)： 当你仅仅使用

UNION
关键字时，SQL数据库会在合并两个或多个结果集后，自动执行一个去重操作。这意味着，如果有多行在所有选定的列上都完全相同，那么最终的结果集中只会保留其中一行。
  • 特点：确保结果集的唯一性。
  • 适用场景：当你需要一个“不重复”的列表时，例如获取所有不重复的客户邮箱地址，或者所有参与过某个项目的不重复人员ID。
  • 性能考量：由于需要额外的去重步骤（通常涉及到排序或哈希操作），
    UNION
    的性能开销会比
    UNION ALL
    高。对于非常大的数据集，这个性能差异可能会很明显。

UNION ALL： 而

UNION ALL
则简单粗暴得多。它将所有SELECT语句的结果集直接堆叠起来，不会进行任何去重。这意味着，如果原始结果集中存在重复的行，它们会全部出现在最终的合并结果中。
  • 特点：保留所有行，包括重复的。
  • 适用场景：当你需要查看所有原始数据，或者你知道原始结果集中不会有重复行（或者重复行对你来说是有意义的，需要保留）时。例如，你可能想统计某个事件的总发生次数，即使是同一个人多次触发，也需要全部记录。
  • 性能考量：因为它不需要额外的去重步骤，
    UNION ALL
    通常比
    UNION
    执行得更快，尤其是在处理大量数据时。

何时选择哪种操作？

我的经验是，优先考虑

UNION ALL
。只有当你明确知道需要去重，并且去重是业务逻辑的一部分时，才使用
UNION
。
  • 如果对重复数据不敏感，或者你知道数据本身就没有重复，请用
    UNION ALL
    。 这样可以节省数据库的计算资源，提高查询速度。比如，你从两个不同的日志表中提取事件记录，即使事件内容完全一样，你也可能需要看到两次，因为它确实发生了两次。
  • 如果业务要求结果集中不能有任何重复，那么
    UNION
    是你的选择。 比如，你要生成一个发送邮件的列表，肯定不希望同一个收件人收到多封邮件。

举个例子，假设我们有两个销售部门的销售记录表

sales_dept_a
和
sales_dept_b
，它们都有
order_id
, 
customer_id
, 
amount
。

如果你想知道所有销售订单的总金额，包括可能在两个部门都有记录的订单（虽然这种情况不常见，但作为例子），并且你希望保留所有记录：

SELECT order_id, customer_id, amount
FROM sales_dept_a
UNION ALL
SELECT order_id, customer_id, amount
FROM sales_dept_b;

但如果你想得到所有购买过的客户的唯一ID列表：

SELECT customer_id
FROM sales_dept_a
UNION
SELECT customer_id
FROM sales_dept_b;

这里

UNION
会确保每个
customer_id
只出现一次。 使用 UNION 操作时需要注意哪些常见陷阱和最佳实践？

在使用UNION操作时，虽然它功能强大，但如果不注意一些细节，很容易掉进坑里，或者写出效率低下的查询。以下是我在使用过程中总结的一些常见陷阱和最佳实践。

常见陷阱：

PIA PIA

全面的AI聚合平台，一站式访问所有顶级AI模型

PIA226 查看详情 PIA

  1. 列不匹配导致的错误或意外结果：

    • 列数量不一致：这是最常见的错误，直接导致SQL语法错误。数据库会明确告诉你SELECT列表中的项数不匹配。
    • 列类型不兼容：虽然有时数据库会尝试隐式转换，但这可能导致数据丢失（例如，将文本转换为数字失败）、数据截断或结果不符合预期。比如，你把一个
      VARCHAR
      类型的日期和
      DATE
      类型的日期UNION，结果可能都是字符串，但格式不统一。
    • 列顺序混乱：这不会导致语法错误，但会导致数据“错位”。比如，第一个SELECT是
      name, email
      ，第二个却是
      email, name
      ，结果就全乱了。

  2. ORDER BY
    子句的位置问题： 
    • ORDER BY
      子句只能应用于整个UNION结果集的最后。如果你在每个SELECT语句内部都添加
      ORDER BY
      ，除了第一个SELECT语句的
      ORDER BY
      可能会被某些数据库忽略外，其他都会报错。正确的做法是，将
      ORDER BY
      放在最后一个SELECT语句的后面，作用于所有合并后的数据。

  3. 性能问题：

    • 滥用
      UNION
      ：如果不需要去重，却使用了
      UNION
      而非
      UNION ALL
      ，会额外消耗资源进行去重操作，尤其是在数据量大时，性能会急剧下降。
    • 复杂的子查询：如果每个SELECT语句本身就包含复杂的JOIN或子查询，那么UNION操作会进一步增加整体查询的复杂度。

最佳实践：

  1. 明确列的定义：

    • 显式列出所有列：不要使用
      SELECT *
      ，尤其是在UNION操作中。这不仅能避免未来表结构变化带来的问题，也能让你清楚地知道哪些列正在被合并。
    • 使用
      CAST
      或
      CONVERT
      强制类型转换：如果列的数据类型确实不兼容，但逻辑上需要合并，可以使用
      CAST
      或
      CONVERT
      函数将它们统一转换为兼容的类型。例如：
      SELECT CAST(numeric_id AS VARCHAR(20)) FROM table1 UNION ALL SELECT string_id FROM table2;
    • 保持列顺序一致：在编写查询时，养成习惯，让所有SELECT语句中的列顺序保持一致。

  2. 合理使用

    UNION ALL
    ：
    • 优先考虑
      UNION ALL
      ：除非你明确需要去重，否则总是使用
      UNION ALL
      。这几乎是SQL性能优化的一个黄金法则。
    • 如果需要去重，但数据量巨大，考虑其他去重策略：例如，先用
      UNION ALL
      合并，然后在外层查询使用
      DISTINCT
      ，或者将结果插入临时表后再去重，有时可能会有更好的性能表现，但这需要具体分析。

  3. ORDER BY
    和
    LIMIT
    的正确使用：
    • 将
      ORDER BY
      放在最后：确保它作用于整个合并后的结果集。
    • LIMIT
      也放在最后：如果你只想获取合并结果集的前N行，
      LIMIT
      子句也应该放在整个UNION查询的末尾。
    (SELECT column1, column2 FROM tableA)
UNION ALL
(SELECT column1, column2 FROM tableB)
ORDER BY column1 DESC
LIMIT 10;

    注意：使用括号将每个SELECT语句包起来，虽然不是强制的，但在某些数据库中能提高可读性，并且在更复杂的场景下（比如与

    ORDER BY
    和
    LIMIT
    结合时）能避免歧义。

  4. 使用别名提高可读性：

    • 虽然最终结果集的列名由第一个SELECT决定，但在每个内部SELECT语句中使用别名可以提高代码的可读性，尤其是在处理复杂的表达式或函数时。

遵循这些实践，能让你更高效、更准确地利用UNION操作，避免不必要的麻烦。

除了 UNION，SQL 中还有哪些可以合并查询结果的方法？

除了UNION，SQL中还有其他几种强大的方式来合并或组合查询结果，它们各有侧重，解决的问题也不同。在我看来，理解这些不同工具的用途，是掌握SQL数据处理能力的关键。

  1. JOIN 操作（连接） 这是SQL中最常用的数据合并方式之一，但它与UNION的理念完全不同。JOIN操作不是将行“堆叠”起来，而是根据两个或多个表之间的关联条件，将它们的列组合起来。

    • 核心思想：横向合并。它通过匹配共享的列（通常是主键和外键），将不同表中的相关信息放在同一行中。
    • 类型：
      • INNER JOIN：只返回两个表中都存在匹配行的记录。
      • LEFT JOIN (LEFT OUTER JOIN)：返回左表中的所有记录，以及右表中匹配的记录。如果右表中没有匹配，则右表的列显示为NULL。
      • RIGHT JOIN (RIGHT OUTER JOIN)：与LEFT JOIN相反，返回右表中的所有记录，以及左表中匹配的记录。
      • FULL OUTER JOIN：返回当左表或右表中有匹配时所有的行。如果某行在另一个表中没有匹配，则对应列显示为NULL。
      • CROSS JOIN：返回两个表的笛卡尔积，即第一个表中的每一行与第二个表中的每一行组合。通常用于生成所有可能的组合。
    • 适用场景：当你需要从多个相关联的表中提取信息，并将它们展示在同一行时。例如，获取订单详情以及下订单的客户信息。
    SELECT o.order_id, o.order_date, c.customer_name, c.email
FROM orders o
INNER JOIN customers c ON o.customer_id = c.customer_id;

  2. 子查询（Subqueries）和公共表表达式（CTEs - Common Table Expressions） 子查询和CTEs本身不是直接合并结果集的操作，但它们是构建复杂查询、分步处理数据、最终达到“合并”效果的重要工具。它们允许你将一个查询的结果作为另一个查询的输入。

    • 核心思想：嵌套查询或分步查询。它们可以用来过滤数据、计算聚合值，或者作为另一个查询的数据源。
    • 子查询：可以将一个SELECT语句嵌套在另一个SELECT、INSERT、UPDATE或DELETE语句中。
      • 例如，
        SELECT * FROM products WHERE category_id IN (SELECT category_id FROM categories WHERE category_name = 'Electronics');
    • CTEs (WITH 子句)：提供了一种更清晰、更可读的方式来组织复杂的查询。你可以定义一个或多个临时的、命名的结果集，然后在后续的查询中引用它们。
      • 适用场景：当你的查询逻辑非常复杂，需要多步处理时，CTEs能极大地提高代码的可读性和可维护性。它们也可以用于递归查询。
    WITH RecentOrders AS (
    SELECT order_id, customer_id, order_date
    FROM orders
    WHERE order_date >= DATE('now', '-7 days')
),
HighValueCustomers AS (
    SELECT customer_id, customer_name
    FROM customers
    WHERE total_spent > 1000
)
SELECT ro.order_id, ro.order_date, hvc.customer_name
FROM RecentOrders ro
INNER JOIN HighValueCustomers hvc ON ro.customer_id = hvc.customer_id;

    这里，CTEs帮助我们清晰地定义了两个独立的逻辑块，然后通过JOIN将它们的结果合并。

  3. INSERT INTO ... SELECT FROM ... 这种方法不是为了在单个查询中“显示”合并结果，而是为了将一个或多个查询的结果永久地合并到一个目标表中。

    • 核心思想：数据迁移或数据整合。它将源查询的结果作为新行插入到目标表中。
    • 适用场景：当你需要将来自不同来源的数据整合到一个统一的报告表、历史表或数据仓库中时。这在ETL（抽取、转换、加载）过程中非常常见。
    -- 假设你有一个空的或需要更新的 consolidated_sales 表
INSERT INTO consolidated_sales (sale_id, product_id, amount, sale_date)
SELECT sale_id, product_id, amount, sale_date FROM daily_sales_region_a
UNION ALL
SELECT sale_id, product_id, amount, sale_date FROM daily_sales_region_b;

    这里，UNION ALL用来合并来自两个区域的日销售数据，然后一次性插入到总销售表中。

每种方法都有其独特的应用场景和优势。UNION适用于行合并，JOIN适用于列合并，而子查询/CTEs和

INSERT INTO ... SELECT
则提供了更灵活的数据处理和持久化能力。理解这些工具，并知道何时选择哪个，是成为一名高效SQL开发者的关键。

以上就是SQL中的UNION操作是什么？合并查询结果的正确方法的详细内容，更多请关注知识资源分享宝库其它相关文章！

相关标签： go 工具 ai 邮箱 数据丢失 隐式转换 sql 数据类型 NULL select date 字符串 union 强制类型转换 递归 堆 delete 类型转换 事件 table 数据库 etl 性能优化 大家都在看： 如何插入查询结果数据_SQL插入Select查询结果方法 SQL临时表存储聚合结果怎么做_SQL临时表存储聚合数据方法 Oracle数据源连接泄露防范_Oracle数据源连接泄漏预防措施 Oracle透明数据源怎么配置_Oracle透明数据源建立方法解析 SQLAVG函数计算时如何保留小数_SQLAVG函数保留小数位方法

标签:  查询结果 合并 正确 

相关阅读

发表评论:

◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。

最近发表

标签列表