UNION操作用于合并多个SELECT结果集，要求列数相同、数据类型兼容，UNION默认去重而UNION ALL保留所有行，后者性能更高；常见于整合分散数据源或跨表查询，需注意性能损耗、隐式转换风险及列顺序匹配问题。
SQL的
UNION
操作，在我看来，是数据库查询中一个非常实用但也需要谨慎使用的工具。它主要的作用就是将两个或多个
SELECT
语句的结果集合并成一个单一的结果集。想象一下你有几张结构相似的表，或者想从同一张表里用不同的条件筛选出数据，然后把它们放在一起，
UNION
就是干这事的。正确地使用它，核心在于理解它对结果集结构（列数、数据类型）的严格要求，以及对重复行的处理方式。
解决方案
UNION
操作的本质，是垂直地将多个查询结果堆叠起来。它要求所有参与
UNION
的
SELECT
语句必须满足两个基本条件：
列数必须完全相同。 如果一个查询有3列，另一个查询有4列，那数据库会直接报错。对应列的数据类型必须兼容。 这意味着第一条
SELECT
语句的第一个列的数据类型，必须能与第二条
SELECT
语句的第一个列的数据类型兼容。兼容不代表完全相同，比如
INT
和
BIGINT
通常可以兼容，但
INT
和
VARCHAR
可能就需要显式转换了。数据库会尝试进行隐式转换，但最好是显式地保持一致，避免意外。
默认情况下，
UNION
操作会自动去除重复的行，这等同于
UNION DISTINCT
。如果你的目的是把所有行都包含进来，即使有重复，那么就应该使用
UNION ALL
。
基本语法：
SELECT column1, column2, ...FROM table1WHERE condition1UNION [ALL | DISTINCT]SELECT column1, column2, ...FROM table2WHERE condition2;
示例：
假设我们有两张表，
employees_hr
和
employees_it
，它们都记录了员工的
id
,
name
,
。
-- 合并两个部门的员工列表，并去除重复的员工（如果ID、姓名、邮箱都相同）SELECT id, name, email FROM employees_hrUNIONSELECT id, name, email FROM employees_it;-- 合并所有员工列表，即使有重复也全部显示SELECT id, name, email FROM employees_hrUNION ALLSELECT id, name, email FROM employees_it;
需要注意的是，最终结果集的列名通常会沿用第一个
SELECT
语句中的列名。
UNION DISTINCT 和 UNION ALL 有什么区别？什么时候该用哪个？
这是
UNION
操作中最核心的一个区分点，也是我个人在实践中经常会去权衡的地方。简单来说，
UNION DISTINCT
（通常简写为
UNION
）会帮你把结果集中的重复行清理掉，而
UNION ALL
则会把所有行都原封不动地返回。
UNION DISTINCT
(或简写为
UNION
)
特点： 它会扫描合并后的结果集，找出所有完全相同的行，然后只保留其中一行。适用场景：需要唯一结果列表时： 比如你想获取所有部门中所有员工的唯一邮箱列表，无论他在多少个部门登记过。数据源可能存在重复数据时： 如果你合并的数据本身就有可能因为某种原因产生重复，而你又不希望在最终报告中看到这些重复，那么
UNION DISTINCT
就是你的首选。集合去重： 当你把
UNION
操作看作是一种集合操作（求并集）时，它自然就包含了去重的逻辑。性能考量： 去重操作通常需要数据库进行额外的排序和比较。对于非常大的数据集，这会消耗更多的CPU和内存资源，导致查询速度变慢。如果性能是你关注的重点，而你又不需要去重，那么就应该避免使用它。
UNION ALL
特点： 它只是简单地将所有
SELECT
语句的结果拼接在一起，不做任何去重处理。适用场景：需要保留所有数据时： 比如你正在收集不同时间段的日志数据，即使日志内容完全相同，你也希望它们都显示出来，因为它们代表了不同的事件发生。性能优先时： 如果你已经确定各个
SELECT
语句的结果集之间不会有重复，或者重复对你来说不是问题，那么使用
UNION ALL
会因为避免了额外的去重步骤而获得更好的性能。它通常比
UNION DISTINCT
快。分片数据合并： 当你将同一个逻辑表的数据分片存储在多个物理表（例如
sales_2022
,
sales_2023
）中，需要查询所有年份的数据时，
UNION ALL
是最佳选择，因为不同年份的数据本身就不会重复。性能考量： 由于没有去重开销，
UNION ALL
的执行效率通常更高。它更像是一个简单的“追加”操作。
总结： 我个人的经验是，在不确定或者对性能要求不高的情况下，
UNION DISTINCT
可以保证结果的唯一性。但一旦数据量上去，或者我明确知道不需要去重时，我一定会优先选择
UNION ALL
。有时候，为了调试方便，我也会先用
UNION ALL
看看原始数据，再决定是否需要去重。
使用 UNION 操作时，如何确保数据类型和列结构兼容性？
确保
UNION
操作中数据类型和列结构兼容性，是写出正确且高效SQL的关键。这不仅仅是避免报错，更是为了保证数据结果的准确性。我的做法通常是先检查，再动手，必要时进行显式转换。
1. 列数的一致性：
这是最基础的。如果列数不一致，数据库会直接抛出错误。所以，在写
UNION
查询前，我会先确认每个
SELECT
语句中选择的列的数量是否完全相同。
腾讯交互翻译
腾讯AI Lab发布的一款AI辅助翻译产品
181 查看详情 
-- 错误示例：列数不一致SELECT id, name FROM table1UNION ALLSELECT id, name, email FROM table2; -- 会报错
2. 数据类型的兼容性与显式转换：
虽然数据库会尝试隐式转换（例如将
INT
转换为
VARCHAR
），但这往往是不可靠的，甚至可能导致数据丢失或不符合预期。
检查数据类型： 在开始编写
UNION
查询之前，我会先查看涉及到的表的结构，特别是那些将要合并的列的数据类型。
使用
CAST()
或
CONVERT()
进行显式转换： 当发现对应列的数据类型不完全一致但又需要合并时，我会主动使用
CAST()
或
CONVERT()
函数来统一数据类型。这不仅能确保兼容性，还能让代码意图更明确，可读性更好。
-- 示例：一个表存储了用户ID为INT，另一个表存储了用户ID为VARCHAR，需要统一SELECT CAST(user_id AS VARCHAR(50)) AS user_identifier, user_nameFROM users_int_idUNION ALLSELECT user_id, user_nameFROM users_users_varchar_id;-- 示例：一个表存储了日期为DATETIME，另一个存储为DATE，需要统一SELECT order_id, CAST(order_datetime AS DATE) AS order_dateFROM orders_full_timeUNION ALLSELECT order_id, order_dateFROM orders_only_date;
3. 列的顺序：
UNION
操作是基于列的顺序来匹配的，而不是基于列名。这意味着第一个
SELECT
语句的第一个列会与第二个
SELECT
语句的第一个列进行匹配，以此类推。所以，即使列名不同，只要顺序和类型兼容，
UNION
也能工作。但为了代码的可读性和避免混淆，我通常会尽量保持列的逻辑顺序一致。
-- 示例：列名不同但顺序和类型兼容SELECT product_id, product_name FROM products_aUNION ALLSELECT item_id, item_description FROM products_b; -- 结果集中，item_id会作为product_id列，item_description作为product_name列
4. 处理不同数量的“逻辑”列：
有时候，你可能需要合并的表在逻辑上是相似的，但其中一张表比另一张表多了一些你不需要的列，或者少了一些你需要的列。这时，可以通过选择性地使用
NULL
或常量来“填充”缺失的列，以达到列数一致。
-- 示例：一个表有地址信息，另一个没有，但我们想在合并结果中显示一个统一的地址列SELECT customer_id, customer_name, address, cityFROM customers_with_addressUNION ALLSELECT customer_id, customer_name, NULL AS address, NULL AS city -- 使用NULL填充缺失的列FROM customers_without_address;-- 示例：合并不同类型的事件日志，但希望有一个统一的事件类型列SELECT log_time, 'Login' AS event_type, user_id, ip_addressFROM login_logsUNION ALLSELECT log_time, 'Purchase' AS event_type, user_id, product_idFROM purchase_logs;
这些技巧能帮助我在面对各种复杂场景时，依然能灵活且正确地运用
UNION
操作。
UNION 操作在实际业务场景中，有哪些常见的应用和潜在的陷阱？
在我的工作经历中，
UNION
操作的出镜率还挺高的，它能解决不少实际问题，但如果用得不好，也确实会带来一些意想不到的麻烦。
常见的应用场景：
整合分散的数据源： 这是最常见的用途。比如，一个大型企业可能有多个业务系统，每个系统都生成类似但独立的数据（如不同区域的销售订单、不同产品的库存记录）。通过
UNION ALL
，我们可以快速将这些分散的数据整合到一个视图中，进行统一的分析和报告。
-- 合并不同区域的销售订单SELECT order_id, customer_id, total_amount, 'North' AS region FROM sales_northUNION ALLSELECT order_id, customer_id, total_amount, 'South' AS region FROM sales_south;
跨表搜索或报告： 当需要从多个结构相似的表中查找信息时，
UNION
可以提供一个统一的查询接口。例如，你可能需要从
active_users
和
inactive_users
两张表中查找某个用户的信息。
-- 查找所有用户（无论活跃与否）的特定信息SELECT user_id, user_name, email FROM active_users WHERE user_name LIKE '%John%'UNIONSELECT user_id, user_name, email FROM inactive_users WHERE user_name LIKE '%John%';
构建复杂的数据视图或报表： 有时候，为了生成一个综合性的报表，我们需要从多个角度或基于不同的筛选条件获取数据，然后将它们合并。
UNION
在这里就显得非常灵活，尤其是在数据仓库或BI场景中。
-- 结合不同条件的客户列表：既是VIP又是活跃的，或者是新注册的SELECT customer_id, customer_name, 'VIP_Active' AS status FROM customers WHERE is_vip = TRUE AND is_active = TRUEUNION ALLSELECT customer_id, customer_name, 'New_Registered' AS status FROM customers WHERE registration_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY);
处理分区表： 在一些数据库系统中，大型表会按时间或其他维度进行分区（例如
logs_2022
,
logs_2023
）。查询跨越多个分区的数据时，
UNION ALL
是直接且高效的方式。
潜在的陷阱和挑战：
性能问题（尤其是
UNION DISTINCT
）： 这几乎是
UNION
操作最常见的痛点。如果涉及的数据量巨大，
UNION DISTINCT
的去重操作会非常耗时，因为它需要对所有结果进行排序和比较。我的建议是，如果能确定数据不会重复，或者重复对业务影响不大，优先使用
UNION ALL
。数据类型隐式转换的坑： 数据库在尝试隐式转换时，可能会导致数据丢失（例如
VARCHAR
转换为
INT
时，非数字字符会报错或变为
NULL
）或不符合预期的结果。这在调试时特别令人头疼，因为错误可能不会立即显现，而是在数据分析阶段才被发现。所以，我总是强调要进行显式转换。列顺序和列名混淆： 刚才提到了，
UNION
是按顺序匹配列的。如果各个
SELECT
语句中的列顺序不一致，即使数据类型兼容，最终的结果集也会是混乱的，字段的含义会错位。此外，结果集的列名通常取自第一个
SELECT
语句，这可能与后续
SELECT
语句的列名不符，容易造成误解。与
JOIN
的误用： 有时候，初学者可能会混淆
UNION
和
JOIN
的使用场景。
UNION
是合并行（垂直合并），而
JOIN
是合并列（水平合并），用于连接相关联的表。如果本来应该用
JOIN
来关联不同表的数据，却错误地使用了
UNION
，那结果将完全不符合预期。调试复杂
UNION
查询的难度： 当一个
UNION
查询涉及到多个
SELECT
语句，每个
SELECT
语句本身又很复杂时，一旦结果不正确，定位问题会变得非常困难。我的经验是，逐个运行
UNION
中的每个
SELECT
语句，确认它们各自的结果是正确的，是调试的有效方法。
总的来说，
UNION
是一个强大的工具，但它的威力伴随着一些使用上的细致要求。理解这些要求，并结合实际业务场景去权衡
UNION DISTINCT
和
UNION ALL
，才能真正发挥它的价值。
以上就是SQL的UNION操作有何作用？合并查询结果的正确方法的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/860398.html
微信扫一扫 
支付宝扫一扫 
