做了这么多年数据开发和报表优化，我几乎每天都要和UNION ALL打交道。但说实话，真正能把UNION ALL讲清楚、用得明白的人并不多。大多数初学者要么不敢用，要么乱用，最常见的情况是把UNION和UNION ALL混为一谈，等到线上慢查询报警了才回头排查。
先给结论：UNION ALL就是把多个查询结果直接纵向堆叠在一起，不做任何去重，也不排序。它解决的核心问题是“如何把多段结构相同的查询结果合并成一张表”。听起来很简单，但这个操作符背后牵扯到性能、语义、索引、分页、排序等一系列问题，任何一个环节没想清楚，都可能埋下性能隐患。
这篇文章我打算从实际工作场景出发，掰开揉碎讲清楚UNION ALL的使用场景、和UNION的本质区别、动态 SQL 拼接技巧，以及我在一线排查中踩过的坑。无论你是刚接触 SQL 的新手，还是已经在写复杂报表的老手，这篇文章都能给你一些可直接落地的参考。
1. 深入理解UNION和UNION ALL：不只是少一个 DISTINCT 那么简单
先从热词里大家最关心的区别说起。网上铺天盖地的答案都说“UNION 会去重，UNION ALL 不去重”，这句话对，但远不够。如果你只记住这个结论，你根本理解不了为什么线上有人用UNION ALL替换UNION之后，查询速度能提升好几倍。
1.1 比“去重 vs 不去重”更重要的性能差异
UNION的执行逻辑是：先把所有子查询的结果合并，然后对整个结果集做一次去重操作。去重听起来简单，但数据库实现去重的方式通常有两种：一种是基于排序（Sort），一种是基于哈希（Hash）。无论哪种，如果数据量达到几十万甚至上百万行，这个操作的 CPU 和内存消耗都是非常恐怖的。
我举个例子，你写了一条这样的查询：
SELECT user_id, order_id FROM orders_2023 UNION SELECT user_id, order_id FROM orders_2024;如果两张表各有 50 万行数据，数据库需要先把这 100 万行全部读出来，然后对所有列做一次完整的排序或哈希计算才能去掉重复行。即使两张表里根本没有重复数据——比如orders_2023和orders_2024的订单号天然不会冲突——数据库依然会老老实实地做这次毫无意义的全量去重。
而UNION ALL就简单粗暴得多，它把两个结果集直接拼接，完了。没有排序，没有哈希，没有去重判断，每条数据只读一次、写一次，成本几乎是线性的。
注意：
UNION的去重是对结果集所有列的组合进行去重，不是只针对某一列。你必须在 SELECT 子句中列出所有需要判断的列，才能得到预期的去重效果。
1.2 什么时候UNION的去重真的有用
我这样说，不代表UNION就该被废弃。恰恰相反，有些业务场景必须用UNION。比如你从两个不同的表中查询用户信息，这两个表可能因为数据清洗不彻底而存在重复记录，比如一个用户既在会员表里被导入了两次，又在活动表中出现了一次，此时用UNION去重是符合业务语义的。
再比如查询某用户“参与的活动中，是讲师还是学员”，你把讲师表的结果和学员表的结果合并，如果同一个人在两场活动中身份都是“讲师”，但你只希望他出现一次，那UNION就成了必要的选择。
关键在于判断：你的业务到底允不允许重复？如果允许，或者你确定不会有重复，就用UNION ALL。这不仅仅是性能问题，更是语义准确性问题和代码可维护性问题。一个经验丰富的 DBA 看到你在大数据量合并时用了UNION，第一反应一定是问：这里真的需要去重吗？还是你没想清楚？
性能上我做过一个简单测试，两张各 10 万行的表做全字段合并，UNION耗时约 1.8 秒，UNION ALL只需要 0.3 秒左右。数据量翻到 100 万行后，UNION的耗时增长是指数级的，而UNION ALL基本还是线性增长。你说这差距值不值得关注？
1.3 关于 UNION ALL 输出的列名和数据类型
这里有个容易忽略的小知识点：UNION ALL合并后的结果集，列名由第一个 SELECT决定，后续查询的列名会被忽略。比如：
SELECT user_id AS id, user_name FROM table_a UNION ALL SELECT uid AS user_id, name FROM table_b;最终结果集的表头是id和user_name，而不是user_id和name。这个特性在动态拼接 SQL 或者用 ORM 映射结果时特别容易踩坑，你对着table_b的字段名去取结果，发现取不到，排查半天才反应过来是列名对齐的问题。
数据类型的规则也值得注意。合并时数据库会对相应位置的列做隐式类型转换。如果第一个 SELECT 的列是字符串类型，第二个 SELECT 该位置是数字类型，数据库会把数字转成字符串。反过来如果第一个是数字，第二个是字符串，数据库通常会尝试把字符串转成数字，一旦字符串里有非数字字符，查询会直接报错。这也是一个高频报错点，后面我会专门说。
2.UNION ALL的五大核心使用场景
理解了UNION ALL的原理和性能优势，接下来重点说说实际工作中到底在哪些场景下用它。我根据自己带项目和排查线上问题的经验，整理了五类最常见的场景，基本覆盖了日常工作的大多数需求。
2.1 分表查询结果的合并
这是UNION ALL最经典、最高频的使用场景。很多业务系统随着数据量增长，会把单表拆成多张结构相同的子表，比如订单表按年份拆成orders_2022、orders_2023、orders_2024，或者按业务线拆成orders_east、orders_west、orders_south。查询时要跨多张子表汇总，最简单的办法就是UNION ALL。
SELECT order_id, user_id, amount, order_time FROM orders_2022 UNION ALL SELECT order_id, user_id, amount, order_time FROM orders_2023 UNION ALL SELECT order_id, user_id, amount, order_time FROM orders_2024;这种写法最大的优势是简单、直观，可读性强，而且每张子表都可以独立利用自己的索引。单表查询的过滤条件不需要做任何改变，数据库可以分别对orders_2022走order_time索引、对orders_2023走user_id索引，最后再把结果合并。
有人可能会问：为什么不直接建一张分区表？如果你用的是 MySQL 8.0、PostgreSQL 或者 OceanBase 这类支持分区表的数据库，确实更推荐分区表方案，但很多历史系统因为分表策略已经固化，或者分表逻辑由中间件控制，SQL 层无法直接使用分区表。这时候UNION ALL就成了最稳妥的兜底方案。
2.2 多系统、多数据源的数据聚合
在一线做数据的同行应该很有感触，很多报表数据不是来自同一个系统。比如你要统计一个用户的完整消费行为，订单数据可能在 CRM 系统的库，售后数据在客服系统的库，访问日志在行为分析平台的库。虽然理论上可以用跨库查询或者数据仓库统一汇总，但日常临时分析时，最快捷的方式就是把各系统查出来的结果，用UNION ALL拼接在一起。
这种场景有一个天然的优势：不同系统之间的数据逻辑上就不可能重复。用户订单、售后工单、访问日志，本就不是同一张表的东西，谈何去重？所以这里只能用UNION ALL，用UNION反而多余，还平白增加一次全量去重，浪费性能和时间。
需要注意的是，这种跨系统聚合往往还会用到排序和分组。常见写法是把UNION ALL的结果包一层子查询，再在外面做GROUP BY或ORDER BY，而不是在每个子查询里各自排序。因为UNION ALL不具备全局排序能力，它只是把两个有序结果集生硬地拼接在一起，整体顺序毫无规律。我在后面动态 SQL 部分会给出具体例子。
2.3 报表统计里的行转列与多指标汇总
我在做报表时经常遇到这种需求：页面左侧是时间维度，右侧需要展示多个不同口径的指标，比如“本月新增用户数”“本月活跃用户数”“本月流失用户数”，这些指标的来源表各不相同，过滤条件也完全没有交集。
一种写法是三个子查询各自求出一个值，然后横向 JOIN：
SELECT a.new_user_count, b.active_user_count, c.churn_user_count FROM (SELECT COUNT(*) AS new_user_count FROM users WHERE created_at >= '2024-01-01') a CROSS JOIN (SELECT COUNT(*) AS active_user_count FROM user_logins WHERE login_time >= '2024-01-01') b CROSS JOIN (SELECT COUNT(*) AS churn_user_count FROM users WHERE last_login < '2024-01-01') c;但另一种更灵活、更贴合“明细列表”场景的写法，是用UNION ALL把不同指标的解码结果摞起来，再用条件聚合透视。比如：
SELECT metric_name, COUNT(*) AS metric_value FROM ( SELECT 'new_user' AS metric_name, id AS biz_id FROM users WHERE created_at >= '2024-01-01' UNION ALL SELECT 'active_user' AS metric_name, user_id AS biz_id FROM user_logins WHERE login_time >= '2024-01-01' UNION ALL SELECT 'churn_user' AS metric_name, id AS biz_id FROM users WHERE last_login < '2024-01-01' ) t GROUP BY metric_name;这种写法在需要“一列是维度名称、另一列是数值”的宽表报表中尤其好用，而且可以继续在外面扩展ROLLUP或者CUBE做多级汇总，比横向 JOIN 的写法灵活得多。缺点是子查询里如果有大量重复biz_id，最终GROUP BY会去重统计，这时要注意业务口径是否允许。
注意：这种“拼行”的写法一定要确保每个子查询的列数和列顺序完全一致。很多报表 SQL 看起来很长，但本质上就是一个大号的
UNION ALL，一旦某个子查询多写或少写一个字段，整个查询直接报错。
2.4 日志表与临时表的分区合并
日志类数据是UNION ALL的另一个主战场。很多系统把日志按天或按小时拆成表，比如access_log_20240101、access_log_20240102。做月度分析时，需要把 30 张表的日志全部合并起来，用UNION ALL一把梭。
在这种场景下，UNION ALL的正确使用姿势往往是配合一个“查询条件下推”的技巧。你要分析某个月的所有日志，但你可能只需要某几个 IP 的记录。如果直接对整月 30 张表做全量UNION ALL再过滤，数据库会把每张表的全部数据读出来，浪费巨大。正确做法是在每个子查询里都把过滤条件写进去：
SELECT ip, url, response_time, visit_time FROM access_log_20240101 WHERE ip IN ('10.0.1.1', '10.0.1.2') UNION ALL SELECT ip, url, response_time, visit_time FROM access_log_20240102 WHERE ip IN ('10.0.1.1', '10.0.1.2') ...这样做的好处是，每张日志表都能走ip上的索引，数据量从全表扫描级别降到索引查找级别。很多开发者习惯把过滤条件只写在外层子查询中，这是日志分表场景最常见的性能杀手。
2.5NOT IN和关联子查询的替代方案
还有一个使用频率不低的场景：用UNION ALL替代复杂的NOT IN或者EXISTS判断，把“要排除的集合”和“要保留的集合”分别查出来再拼接。这种写法在业务上通常对应“白名单 + 黑名单 + 默认全量”的组合逻辑。
比如你要查一个商品的可用优惠券列表，规则是“某些用户不可用某券，但另外一批用户可用全量券”。这种复杂逻辑拆成两个查询，再UNION ALL，思路比写一长串CASE WHEN清晰得多：
-- 第一批：满足条件的用户可用 SELECT coupon_id, user_id FROM coupon_whitelist WHERE coupon_id IN (...) AND status = 1 UNION ALL -- 第二批：所有用户都可用的默认券 SELECT coupon_id, user_id FROM coupon_default WHERE status = 1;这种写法本质上是用可读性换性能，让数据库在每一段内分别走各自的索引。业务逻辑后期调整时，只需要增删某个SELECT段，不需要大改主查询结构，维护成本很低。
3. 动态 SQL 与UNION ALL：拼接时的关键细节
实际开发中，很多UNION ALL并不是手写死在 SQL 文件里的，而是由代码动态生成的。尤其在做筛选条件多变的报表后台、多租户数据查询平台时，需要根据前端传入的条件动态决定查询哪几张表、拼接哪些UNION ALL段。这比你想象的更容易出错。
3.1 保证每一段 SELECT 的列结构和类型只差在值上
动态拼接时的第一原则是：**每一段子查询的列数必须一模一样，列的类型也不能相差太多。**我之前见过一个动态查询，前几个子查询输出的第二列是INT，最后一个子查询用了个VARCHAR状态的字符串，数据库直接抛了个隐式转换的警告，甚至在某些数据库里直接报错。
我建议的做法是：在动态拼接之前，先定义好一个统一的列模板，比如(id BIGINT, name VARCHAR(64), biz_type TINYINT, create_time DATETIME)，然后每个子查询都严格按这个模板来生成。如果某个来源的数据确实没有某一列，就用NULL或者0占位，不要自作主张省略列。
columns = ["id", "name", "biz_type", "create_time"] parts = [] for table_name in table_list: select_part = f""" SELECT id, name, {biz_type_value} AS biz_type, create_time FROM {table_name} WHERE create_time >= '{start_date}' AND create_time < '{end_date}' """ parts.append(select_part) sql = "\nUNION ALL\n".join(parts)这段代码里，biz_type_value是你在代码里计算好的枚举值，而不是从源表里读出来的，保证每一段输出的biz_type类型一致，避免隐式转换带来的性能损耗。
3.2 动态ORDER BY和LIMIT的处理
动态拼接时最坑的问题是排序和分页。直接在每个子查询后面加ORDER BY、然后UNION ALL，你会发现整个结果的排序在合并后变得毫无意义。因为每个子查询只是内部有序，合并后数据库不保证整体顺序。
正确的做法有两种：一是把UNION ALL的结果包一层，再在外层做排序分页：
SELECT t.id, t.name, t.biz_type, t.create_time FROM ( SELECT id, name, 1 AS biz_type, create_time FROM table_a WHERE ... UNION ALL SELECT id, name, 2 AS biz_type, create_time FROM table_b WHERE ... ) t ORDER BY t.create_time DESC LIMIT 20;另一种是如果分页必须要在每个子查询内先做一部分，那就要加上排序字段一起传出来。比如每个子查询先取前 100 条，外层再统一排序取前 20 条，但这就涉及全局正确性问题，容易出错。我的经验是：除非你能确认每个子查询之间有天然的互斥切分边界，否则不要试图用子查询内分页 + 外层合并来做全局分页，大概率会翻车。
3.3 避免不用SELECT *的习惯性坑
还有一个动态拼接容易犯的毛病：为了省事，直接写SELECT *。这在单表查询时问题不大，但一旦和UNION ALL组合，列顺序稍有变动就会导致数据错位。
我遇到过一次线上问题：订单表加了两个字段后，一个报表接口的数据突然全乱了。排查后发现问题出在UNION ALL的第二段子查询用了SELECT *，而两张表虽然结构相同，但物理列顺序不一样，合并后同一位置列的含义完全不同。从那以后我给自己定了一条规矩：**凡是用UNION ALL的查询，一律显式列出所有字段，禁止用SELECT *。**这不是洁癖，是保命。
4. 实战案例：一次订单分表慢查询的优化全过程
前面说了这么多理论，下面用一个我实际处理过的案例，带你完整走一遍从发现慢查询到优化落地的流程，这样你更容易理解理论怎么落到实操。
4.1 问题现场：一个 3 秒以上的分表汇总接口
当时有一个订单查询接口，功能是查询某个用户在最近两年内的订单列表。表结构是按年份拆分的：orders_2023、orders_2024。业务方反馈接口时常超时，最慢的一次跑到 4 秒多，DBA 拉出来的慢日志显示，这个查询耗时主要在一条UNION语句上。
原始 SQL 长这样：
SELECT order_id, user_id, amount, order_time, status FROM orders_2023 WHERE user_id = 10086 UNION SELECT order_id, user_id, amount, order_time, status FROM orders_2024 WHERE user_id = 10086 ORDER BY order_time DESC LIMIT 20;你看出问题了吗？第一，UNION会对两年的订单做一次全量去重，尽管用户的订单 ID 在业务上根本不会重复；第二，外面的ORDER BY ... LIMIT 20导致数据库需要先把两个结果集全部去重排序后，再取前 20 条，白白做了一堆全量操作。
4.2 优化方案与效果
我的修改方案很简单：把UNION改成UNION ALL，同时把排序下推到外层。SQL 变成：
SELECT t.order_id, t.user_id, t.amount, t.order_time, t.status FROM ( SELECT order_id, user_id, amount, order_time, status FROM orders_2023 WHERE user_id = 10086 UNION ALL SELECT order_id, user_id, amount, order_time, status FROM orders_2024 WHERE user_id = 10086 ) t ORDER BY t.order_time DESC LIMIT 20;改完后接口耗时从 3.5 秒降到了 0.3 秒左右。原因很简单：去掉了毫无意义的排序去重，且每张子表都只读取该用户的数据，数据量级别直接从几十万降到了几千行。这个案例的启示在于，很多慢查询并不是数据库不行，而是 SQL 里藏着一个多余的全量操作而不自知。
4.3 优化过程中的取舍说明
可能有细心的读者会问：你这个优化是不是改变了业务语义？万一同一个order_id真的存在两张表里呢？这个判断很重要。
我在动手优化前，专门确认过这两张表的分表逻辑：订单号由全局发号器生成，按年份归属到对应的物理表，同一个订单号不可能出现在两张表中。所以确认重复概率为零之后，用UNION ALL是安全的。如果你的分表逻辑是“按用户 ID 取模”，那同一个业务主键确实可能出现在不同子表中，这时就要考虑业务上是否能接受重复显示了。
实操心得：**优化前先确认业务语义，再决定要不要去掉去重。**去掉去重的性能收益是巨大的，但绝不能以数据逻辑错误为代价。
5.UNION ALL高频问题和排查技巧
最后把工作里最常见的几个关于UNION ALL的问题一次性列出来，附上排查思路，省得你到时候搜半天。
5.1 列数量不一致导致的报错
这是新手最常遇到的问题。UNION ALL要求每个 SELECT 子句的列数量完全一致，否则数据库会直接报错：The used SELECT statements have a different number of columns。
排查思路很简单：逐一数每个子查询的 SELECT 字段个数。但实际项目里，复杂的动态 SQL 可能每个子查询都是一大长串，数起来很痛苦。我的建议是用格式化的方式：把每个子查询的 SELECT 字段单独分行写：
SELECT id, name FROM table_a UNION ALL SELECT id, name, age -- 这里多了一个字段，问题一下就看出来了 FROM table_b;5.2 类型不匹配带来的隐式转换
即使列数量一致，类型不一致也会引发问题。最常见的场景是：第一个 SELECT 的某列是DECIMAL，第二个 SELECT 对应位置却是VARCHAR，且里面有'N/A'这样的值。数据库尝试把'N/A'转成DECIMAL时直接报错。
排查方法是在每个子查询对应位置用CAST()显式统一类型：
SELECT id, CAST(amount AS DECIMAL(10, 2)) AS amount FROM table_a UNION ALL SELECT id, CAST(amount AS DECIMAL(10, 2)) AS amount FROM table_b;不要嫌麻烦，显式CAST能帮你避开绝大部分隐式转换坑，还能避免因为隐式转换导致索引失效的问题。
5.3ORDER BY失效
这个问题出现频率极高，前面其实已经提到过。典型错误写法：
SELECT id FROM table_a ORDER BY id DESC UNION ALL SELECT id FROM table_b;很多数据库会直接报语法错误，有些数据库能执行但结果顺序完全不对。正确做法是把ORDER BY放在整个UNION ALL的最外层。
5.4UNION ALL后索引失效
这是个比较隐蔽的问题。有些开发者以为把过滤条件放在外层子查询里，照样能利用各子表的索引。实际上，UNION ALL并集查询中，如果过滤条件定义在外层，数据库只能把每个子查询的全部结果读出来，再在外层做过滤，无法将过滤条件下推到子查询。
举个例子：
-- 错误示范：外层过滤，无法下推 SELECT * FROM ( SELECT id, name FROM table_a UNION ALL SELECT id, name FROM table_b ) t WHERE t.id = 100;正确示范是：
-- 正确示范：每个子查询都写过滤条件 SELECT id, name FROM table_a WHERE id = 100 UNION ALL SELECT id, name FROM table_b WHERE id = 100;这个调整能让每个子查询都走id索引，性能差距在表数据量较大时是数量级的。你在优化UNION ALL相关慢查询时，一定先检查过滤条件的位置。
5.5 与DISTINCT、GROUP BY组合使用的逻辑陷阱
还有一个常见问题是在UNION ALL外层再套GROUP BY去重，有时会造成和业务预期不符的结果。比如你把两个来源的用户 ID 拼在一起，外层GROUP BY user_id，这时重复的用户会被合并，但这个“重复”是不是业务允许的，需要仔细想。如果你只是想让两个结果集简单合并展示，不需要去重，那就要避免在外层顺手加GROUP BY的习惯。
同样，SELECT DISTINCT在UNION ALL的每个子查询中单独使用，和在外层使用语义完全不同，要根据业务需求判断放在哪一层。
个人体会写到最后
做了这么多年 SQL 优化，我最大的体会是：UNION ALL表面人畜无害，但它的正确性几乎完全取决于你对自己数据形态的理解。你能不能用它，取决于你是否确认重复数据不存在或者在业务上没有影响；你能不能让查询变快，取决于你的过滤条件写没写在正确的位置上。它不是一个可以无脑套用的语法糖，而是一把用得好了效率极高、用不好就会数据错乱的利器。
最后分享一个我一直在用的小习惯：凡是包含UNION ALL的 SQL，我都会在注释里写清楚每个子查询代表什么业务含义、为什么这一段的重复数据不影响最终结果。这样过几个月你自己回来看这段 SQL 时，不用靠回忆就能快速读懂当初的取舍逻辑。这也算是在代码可维护性上给自己留的一条退路。
