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 table1 WHERE condition1 UNION [ALL | DISTINCT] SELECT column1, column2, ... FROM table2 WHERE condition2;
示例：
假设我们有两张表，
employees_hr和
employees_it，它们都记录了员工的
id,
name,
-- 合并两个部门的员工列表，并去除重复的员工（如果ID、姓名、邮箱都相同） SELECT id, name, email FROM employees_hr UNION SELECT id, name, email FROM employees_it; -- 合并所有员工列表，即使有重复也全部显示 SELECT id, name, email FROM employees_hr UNION ALL SELECT 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语句中选择的列的数量是否完全相同。
-- 错误示例：列数不一致 SELECT id, name FROM table1 UNION ALL SELECT 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_name FROM users_int_id UNION ALL SELECT user_id, user_name FROM users_users_varchar_id; -- 示例：一个表存储了日期为DATETIME，另一个存储为DATE，需要统一 SELECT order_id, CAST(order_datetime AS DATE) AS order_date FROM orders_full_time UNION ALL SELECT order_id, order_date FROM orders_only_date;
3. 列的顺序：
UNION操作是基于列的顺序来匹配的，而不是基于列名。这意味着第一个
SELECT语句的第一个列会与第二个
SELECT语句的第一个列进行匹配，以此类推。所以，即使列名不同，只要顺序和类型兼容，
UNION也能工作。但为了代码的可读性和避免混淆，我通常会尽量保持列的逻辑顺序一致。
-- 示例：列名不同但顺序和类型兼容 SELECT product_id, product_name FROM products_a UNION ALL SELECT item_id, item_description FROM products_b; -- 结果集中，item_id会作为product_id列，item_description作为product_name列
4. 处理不同数量的“逻辑”列：
有时候，你可能需要合并的表在逻辑上是相似的，但其中一张表比另一张表多了一些你不需要的列，或者少了一些你需要的列。这时，可以通过选择性地使用
NULL或常量来“填充”缺失的列，以达到列数一致。
-- 示例：一个表有地址信息，另一个没有，但我们想在合并结果中显示一个统一的地址列 SELECT customer_id, customer_name, address, city FROM customers_with_address UNION ALL SELECT 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_address FROM login_logs UNION ALL SELECT log_time, 'Purchase' AS event_type, user_id, product_id FROM purchase_logs;
这些技巧能帮助我在面对各种复杂场景时，依然能灵活且正确地运用
UNION操作。
UNION 操作在实际业务场景中，有哪些常见的应用和潜在的陷阱？
在我的工作经历中，
UNION操作的出镜率还挺高的，它能解决不少实际问题，但如果用得不好，也确实会带来一些意想不到的麻烦。
常见的应用场景：
-
整合分散的数据源： 这是最常见的用途。比如，一个大型企业可能有多个业务系统，每个系统都生成类似但独立的数据（如不同区域的销售订单、不同产品的库存记录）。通过
UNION ALL
，我们可以快速将这些分散的数据整合到一个视图中，进行统一的分析和报告。-- 合并不同区域的销售订单 SELECT order_id, customer_id, total_amount, 'North' AS region FROM sales_north UNION ALL SELECT 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%' UNION SELECT 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 = TRUE UNION ALL SELECT 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，才能真正发挥它的价值。
