1. 这不是语法糖是Oracle里最常被误用的“数据拼接术”很多人第一次在Oracle里写UNION是为了解决一个看似简单的问题把两个表里结构相同的数据“合在一起看”。比如某次项目里A同学需要把“上季度已结案客户”和“本季度待跟进客户”的名单合并成一张报表他直接写了SELECT cust_id, cust_name, 已结案 AS status FROM t_customer_archive UNION SELECT cust_id, cust_name, 待跟进 AS status FROM t_customer_active;结果导出Excel一看——少了37条记录。他反复检查WHERE条件、字段类型、NULL值处理折腾两小时没定位原因最后发现UNION默认去重。这根本不是“拼接”而是“集合运算”。它背后是关系代数里的并集∪定义结果集中不允许存在完全相同的元组。而cust_idcust_namestatus三字段组合一旦重复哪怕来源表不同也会被无情剔除。这不是Bug是设计契约不是性能问题是语义陷阱。我见过太多人把UNION当UNION ALL用又把UNION ALL当FULL OUTER JOIN用最后在生产环境查半天慢SQL才发现执行计划里多出了一个巨大的SORT UNIQUE操作——那正是UNION在默默做去重。它不声不响吃掉你20%的CPU还让你查不出原因。所以今天这篇不讲语法手册里抄来的定义只讲我在真实项目里踩过、修过、优化过、教新人时反复强调的四件事为什么UNION比UNION ALL慢慢在哪一步不只是“因为去重”这种废话UNION和UNION ALL在执行计划里到底长什么样怎么看懂那堆VIEW、SORT、UNIQUE节点当你真需要“合并去重”时有没有比UNION更稳、更快、更可控的替代方案最关键的什么场景下必须用UNION什么场景下用它就是技术债这些答案不会出现在Oracle官方文档的“Syntax”章节里但会决定你写的SQL在千万级数据量下是秒出还是让DBA半夜打电话叫你起床。2. 执行计划解剖室一眼看穿UNION的“心脏手术”要真正理解UNION的代价不能只看SQL写法必须钻进执行计划Execution Plan里像外科医生一样观察它的每一步操作。我们用一个可复现的测试案例来演示——这是我在某高校实验室给学生做的标准教学用例。2.1 构建最小可验证环境-- 创建两张结构完全一致的测试表Oracle 19c CREATE TABLE t_sales_q1 ( sale_id NUMBER PRIMARY KEY, prod_code VARCHAR2(10), amount NUMBER(10,2), region VARCHAR2(20) ); CREATE TABLE t_sales_q2 ( sale_id NUMBER PRIMARY KEY, prod_code VARCHAR2(10), amount NUMBER(10,2), region VARCHAR2(20) ); -- 各插入5万条模拟数据注意故意让部分prod_code重复 INSERT /* APPEND */ INTO t_sales_q1 SELECT LEVEL, CASE WHEN MOD(LEVEL, 7) 0 THEN P001 ELSE P || LPAD(LEVEL, 4, 0) END, ROUND(DBMS_RANDOM.VALUE(100, 5000), 2), CASE WHEN MOD(LEVEL, 3) 0 THEN 华东 ELSE 华南 END FROM DUAL CONNECT BY LEVEL 50000; INSERT /* APPEND */ INTO t_sales_q2 SELECT LEVEL 50000, CASE WHEN MOD(LEVEL, 11) 0 THEN P001 ELSE P || LPAD(LEVEL, 4, 0) END, ROUND(DBMS_RANDOM.VALUE(100, 5000), 2), CASE WHEN MOD(LEVEL, 5) 0 THEN 华北 ELSE 西南 END FROM DUAL CONNECT BY LEVEL 50000; COMMIT; EXEC DBMS_STATS.GATHER_TABLE_STATS(USER, T_SALES_Q1); EXEC DBMS_STATS.GATHER_TABLE_STATS(USER, T_SALES_Q2);提示这里特意让P001在两张表中都高频出现是为了制造UNION必须去重的典型场景。实际业务中这种“跨表同码”极其常见——比如不同渠道录入的同一商品编码、不同系统同步的同一客户ID。2.2 对比UNION与UNION ALL的执行计划本质差异执行以下两条语句并用EXPLAIN PLAN FOR获取计划-- 语句AUNION带去重 EXPLAIN PLAN FOR SELECT prod_code, SUM(amount) amt FROM t_sales_q1 GROUP BY prod_code UNION SELECT prod_code, SUM(amount) amt FROM t_sales_q2 GROUP BY prod_code; -- 语句BUNION ALL无去重 EXPLAIN PLAN FOR SELECT prod_code, SUM(amount) amt FROM t_sales_q1 GROUP BY prod_code UNION ALL SELECT prod_code, SUM(amount) amt FROM t_sales_q2 GROUP BY prod_code;然后查看计划SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);关键差异点如下表所示截取核心OPERATION列步骤UNION执行计划片段UNION ALL执行计划片段差异解读1HASH GROUP BYt_sales_q1HASH GROUP BYt_sales_q1两表各自分组无区别2HASH GROUP BYt_sales_q2HASH GROUP BYt_sales_q2同上3VIEW名称类似VW_NSO_1UNION-ALLUNION会先将两个结果集包装成一个内联视图Inline View这是去重前的必经缓冲区UNION ALL直接标记为集合操作节点4SORT UNIQUE—核心代价所在UNION在此步对所有输入行按全部SELECT列进行全排序再逐行比对去重。5万5万10万行排序复杂度O(n log n)内存不足时还会写入TEMP表5NESTED LOOPS若后续有JOINNESTED LOOPS同左去重后的结果集才参与后续操作意味着后续所有JOIN/ORDER BY都基于更小但已排序的数据集注意SORT UNIQUE不是简单的“去个重”它是Oracle实现集合去重的标准算法——先排序再扫描相邻行判断是否重复。这意味着如果你的SELECT列表有10个字段它就要对这10个字段做复合排序如果其中包含CLOB或LONG等大对象该步骤会直接失败ORA-00932如果SORT_AREA_SIZE设置过小大量数据会溢出到磁盘TEMP表I/O飙升。我曾在一个金融项目里遇到过真实案例一张UNION查询在测试库跑2秒在生产库跑18分钟。DBA抓到执行计划后发现SORT UNIQUE步骤占用了92%的执行时间且Temp Space Used高达12GB。原因很简单——生产库SORT_AREA_SIZE是默认值64KB而测试库被调成了256MB。UNION的性能一半取决于数据本身一半取决于你的内存配置。2.3 一个反直觉的真相UNION ALL未必比UNION快但一定更可预测很多开发者认为“既然UNION ALL不用排序那它一定更快”。错。在某些特定场景下UNION ALL反而更慢。比如-- 场景你需要最终结果按prod_code排序且数据量极大 SELECT * FROM ( SELECT prod_code, amt FROM t_sales_q1 GROUP BY prod_code UNION ALL SELECT prod_code, amt FROM t_sales_q2 GROUP BY prod_code ) ORDER BY prod_code;这个查询的执行计划是先分别对两张表做HASH GROUP BY快然后UNION ALL拼接极快O(1)最后对全部10万行做SORT ORDER BY慢而如果写成SELECT prod_code, amt FROM t_sales_q1 GROUP BY prod_code UNION SELECT prod_code, amt FROM t_sales_q2 GROUP BY prod_code ORDER BY prod_code;执行计划是两张表各自HASH GROUP BY同上SORT UNIQUE对10万行排序去重SORT ORDER BY被优化掉了因为SORT UNIQUE已经按所有列排好序Oracle直接复用该排序结果输出。实测数据10万行Oracle 19cUNION ALL ORDER BY平均耗时 1.8sUNION ORDER BY平均耗时 1.3s提示这个现象在Oracle 12c及以上版本普遍存在。UNION的SORT UNIQUE和显式ORDER BY共享排序缓冲区而UNION ALL之后的ORDER BY必须重新排序。所以当你明确需要最终有序时UNION反而可能是更优解——前提是去重逻辑本身符合业务需求。3. 替代方案实战录什么时候该果断放弃UNIONUNION不是银弹。在真实项目中我总结出三类高危场景一旦出现就必须立刻评估替代方案。下面给出每种场景的诊断信号、推荐替代方案、实操代码对比及我的踩坑心得。3.1 危险信号UNION用于“补缺”而非“合并”——你其实在模拟LEFT JOIN典型症状第一个SELECT查主表A第二个SELECT查关联表B但B中可能缺失某些A的记录你用UNION把A的全量和B的匹配结果拼起来再靠ROWNUM或CASE标记得失执行计划里出现UNION节点但两个分支的CARDINALITY预估行数差异巨大比如1000 vs 5。错误写法示例-- 想查所有客户及其最新订单金额但有些客户没下单 SELECT c.cust_id, c.cust_name, NULL AS last_order_amt FROM t_customer c WHERE c.cust_id NOT IN (SELECT DISTINCT o.cust_id FROM t_order o) UNION SELECT c.cust_id, c.cust_name, o.amt AS last_order_amt FROM t_customer c JOIN t_order o ON c.cust_id o.cust_id WHERE o.order_date (SELECT MAX(o2.order_date) FROM t_order o2 WHERE o2.cust_id c.cust_id);这个SQL的问题在于NOT IN子查询在UNION左侧导致无法利用索引全表扫描右侧的关联子查询嵌套过深执行计划复杂UNION在这里毫无意义——它只是把“没订单客户”和“有订单客户”强行拼成一张表但业务逻辑上它们本应是一体的。正确替代标准LEFT JOIN 窗口函数SELECT c.cust_id, c.cust_name, o.last_order_amt FROM t_customer c LEFT JOIN ( SELECT cust_id, amt AS last_order_amt, ROW_NUMBER() OVER (PARTITION BY cust_id ORDER BY order_date DESC) rn FROM t_order ) o ON c.cust_id o.cust_id AND o.rn 1;为什么更好执行计划清晰HASH JOINWINDOW SORT无UNION节点ROW_NUMBER()窗口函数天然支持“每个客户取最新订单”无需子查询嵌套LEFT JOIN语义明确数据库优化器能更好估算基数性能提升实测原UNION方案平均2.4s新方案0.35s数据量10万客户50万订单。我的踩坑心得在某电商后台项目中一个报表页加载超时DBA抓到罪魁祸首就是这类“伪UNION”。当时开发团队坚持说“UNION逻辑更清晰”直到我把执行计划里那个红色的FILTER节点代表未走索引的NOT IN放大给他们看并现场改写为LEFT JOIN页面响应从12秒降到0.8秒。清晰的逻辑不等于清晰的执行路径。SQL的“可读性”必须以“可执行性”为前提。3.2 危险信号UNION用于“动态列拼接”——你其实在对抗Oracle的范式设计典型症状为了兼容不同业务线的数据结构把N张字段名不同但业务含义相似的表用UNION硬凑成一张宽表SELECT列表里大量使用NULL AS col_x来对齐字段UNION分支超过3个且每个分支都有复杂的WHERE过滤。错误写法示例-- 整合三个部门的销售数据字段名不统一 SELECT dept_id, sales_amt AS total_amt, NULL AS bonus, Q1 AS quarter FROM dept_a_q1 UNION SELECT dept_id, NULL AS total_amt, bonus_amt AS bonus, Q1 AS quarter FROM dept_b_q1 UNION SELECT dept_id, sales_value AS total_amt, bonus_value AS bonus, Q1 AS quarter FROM dept_c_q1;问题在于每个NULL AS xxx都会增加UNION的列对齐开销Oracle必须为每个NULL推断数据类型和长度可能导致隐式转换三个分支的CARDINALITY预估偏差大优化器容易选错连接方式。正确替代标准化中间层视图 应用层聚合第一步创建统一视图一次定义处处复用CREATE OR REPLACE VIEW v_sales_standard AS SELECT dept_id, sales_amt AS total_amt, NULL AS bonus, Q1 AS quarter, DEPT_A AS source_dept FROM dept_a_q1 UNION ALL SELECT dept_id, NULL AS total_amt, bonus_amt AS bonus, Q1 AS quarter, DEPT_B AS source_dept FROM dept_b_q1 UNION ALL SELECT dept_id, sales_value AS total_amt, bonus_value AS bonus, Q1 AS quarter, DEPT_C AS source_dept FROM dept_c_q1;第二步应用层如PL/SQL过程或Java服务按需聚合-- 需要总销售额直接SUM SELECT dept_id, SUM(NVL(total_amt, 0)) AS total_sales FROM v_sales_standard GROUP BY dept_id; -- 需要奖金汇总直接SUM SELECT dept_id, SUM(NVL(bonus, 0)) AS total_bonus FROM v_sales_standard GROUP BY dept_id;为什么更好视图用UNION ALL避免去重开销且source_dept字段让数据可追溯NVL()函数在聚合层处理NULL比在UNION分支里写NULL AS xxx更高效业务逻辑解耦DBA维护视图结构开发按需调用聚合SQL互不干扰。我的踩坑心得某集团财务系统曾因这类“大UNION”导致月结卡死。运维发现v$session_longops里有个UNION操作跑了47分钟。我们拆解后发现三个分支表的数据量分别是200万、80万、1500万但UNION强制把1500万行和其他两表一起排序去重内存爆满。改成UNION ALL视图应用层聚合后月结时间从1.5小时降到22分钟。不要让数据库替你做应用层该做的事。UNION是集合运算不是ETL工具。3.3 危险信号UNION用于“分页伪优化”——你其实在制造分布式事务幻觉典型症状为绕过OFFSET分页的性能问题把大表按条件拆成多个小查询再用UNION拼起来UNION分支里有ROWNUM 100之类的限制查询结果总数不准翻页时数据重复或丢失。错误写法示例-- 想分页查所有活跃用户按注册时间倒序 SELECT * FROM ( SELECT user_id, reg_time, A AS type FROM t_user WHERE reg_time DATE 2023-01-01 AND ROWNUM 50 UNION SELECT user_id, reg_time, B AS type FROM t_user WHERE reg_time DATE 2023-01-01 AND ROWNUM 50 ) WHERE ROWNUM 50;致命问题ROWNUM 50在UNION分支内执行是“每个分支取前50”不是“全局取前50”如果A分支50条全是2023年注册的B分支50条全是2022年注册的最终结果里就没有2023年12月的用户——因为他们的reg_time在A分支里排第51位被ROWNUM截断了UNION去重后总数可能少于50且顺序完全不可控。正确替代标准分页 覆盖索引-- 创建覆盖索引关键 CREATE INDEX idx_user_regtime_id ON t_user(reg_time DESC, user_id); -- 使用标准分页Oracle 12c SELECT user_id, reg_time FROM t_user ORDER BY reg_time DESC, user_id OFFSET 0 ROWS FETCH NEXT 50 ROWS ONLY;为什么更好覆盖索引让ORDER BY reg_time DESC走索引扫描避免全表排序OFFSET/FETCH是Oracle原生分页语法优化器知道这是分页场景会启用WINDOW NOSORT STOPKEY优化结果严格按时间倒序无重复无遗漏总数精准。我的踩坑心得某社交App的“热门用户”接口上线后投诉“刷不出新用户”。排查发现前端用UNION分页后端DBA为提速加了/* INDEX(t_user idx_user_regtime) */提示但UNION分支内的ROWNUM依然在索引扫描后截断导致新注册用户永远进不了前50。改成OFFSET/FETCH后问题彻底消失。分页的本质是“跳过前N行”不是“从M个子集里各取K行”。用错工具再好的索引也救不了。4. 生产环境避坑指南UNION使用的七条铁律在交付过37个Oracle核心系统后我把关于UNION的血泪教训浓缩成七条可直接写进团队SQL规范的铁律。每一条都配有一个真实故障案例和修复代码。4.1 铁律一UNION前必加注释说明“为何必须去重”规则任何UNION语句上方必须用/* */注释明确写出业务原因。禁止出现无注释的UNION。错误示范SELECT id, name FROM table_a UNION SELECT id, name FROM table_b; -- ❌ 无注释半年后没人知道为啥要去重正确示范/* UNION required: table_a and table_b may contain duplicate customer IDs from legacy sync, business rule mandates single view per customer */ SELECT id, name FROM table_a UNION SELECT id, name FROM table_b; -- ✅ 注释说明数据来源、重复原因、业务依据故障案例某银行信贷系统一个UNION查询突然变慢。DBA查执行计划发现SORT UNIQUE占90%时间但没人知道这个UNION存在的意义。翻Git历史发现三年前一位离职同事写的注释只有// merge data。最终业务方确认该场景下重复数据已通过ETL清洗UNION可安全改为UNION ALL性能提升4倍。没有注释的UNION就是定时炸弹。4.2 铁律二UNION分支的字段类型必须显式CAST禁止依赖隐式转换规则当分支字段类型不一致时如VARCHAR2(10)vsCHAR(10)必须用TO_CHAR()、TO_NUMBER()等显式转换且转换后长度/精度需对齐。错误示范SELECT code FROM table_x -- code is VARCHAR2(10) UNION SELECT code FROM table_y; -- code is CHAR(10), trailing spaces cause unexpected duplicatesCHAR(10)字段末尾的空格会被视为有效字符导致ABC 和ABC被视为不同值但业务上它们是同一个编码。UNION去重失效。正确示范SELECT TRIM(code) AS code FROM table_x -- 显式TRIM UNION SELECT TRIM(code) AS code FROM table_y; -- 或更严谨 SELECT TO_CHAR(code) AS code FROM table_x UNION SELECT TO_CHAR(code) AS code FROM table_y;故障案例某零售系统商品主数据同步UNION后发现同一商品出现两条记录。DBA查DUMP()函数发现源系统A传的是VARCHAR2源系统B传的是CHAR(20)末尾15个空格。UNION认为它们不同全保留。加TRIM()后问题解决。Oracle的字符串比较是字节级的空格也是字符。别指望数据库替你理解业务语义。4.3 铁律三UNION分支的WHERE条件必须能走索引禁止在UNION后加WHERE规则过滤条件必须下推到每个UNION分支内部禁止写成SELECT * FROM (UNION) WHERE ...。错误示范SELECT * FROM ( SELECT id, name, A AS src FROM table_a UNION SELECT id, name, B AS src FROM table_b ) WHERE name LIKE John%; -- ❌ 过滤在UNION后全量数据先拼再筛正确示范SELECT id, name, A AS src FROM table_a WHERE name LIKE John% UNION SELECT id, name, B AS src FROM table_b WHERE name LIKE John%; -- ✅ 过滤下推各分支独立走索引故障案例某医疗HIS系统患者查询原SQL在UNION后加WHERE patient_name ?导致每次查询都全表扫描两张表各500万行。改为下推后利用patient_name索引响应时间从8秒降到0.03秒。UNION不是魔法盒它不会帮你优化里面的SQL。把过滤留在外面等于放弃所有索引。4.4 铁律四UNION结果集必须有唯一标识列禁止仅靠业务字段去重规则UNION的SELECT列表中必须包含一个能唯一标识数据来源的列如source_table、etl_batch_id且该列参与去重判断。错误示范SELECT cust_id, cust_name FROM table_legacy UNION SELECT cust_id, cust_name FROM table_new; -- ❌ 仅靠cust_id去重丢失来源信息问题如果table_legacy和table_new里都有cust_id1001UNION会删掉一个但你不知道删掉的是哪个系统的数据也无法审计。正确示范SELECT cust_id, cust_name, LEGACY AS source_system FROM table_legacy UNION SELECT cust_id, cust_name, NEW AS source_system FROM table_new; -- ✅ source_system参与去重数据可追溯故障案例某电信运营商客户资料合并因UNION未带来源标识导致客服查不到某客户的套餐变更记录——因为UNION把旧系统里的变更记录和新系统里的当前状态当成重复数据去掉了。加source_system后业务方能明确看到“该客户在旧系统有3条记录在新系统有1条”决策权回归业务。去重不是删除是归并。没有来源标识的归并就是数据自杀。4.5 铁律五UNION分支数量超过3个时必须重构为WITH子句规则当UNION分支≥3时禁止连续写UNION必须用WITH子句分解每个分支命名清晰。错误示范SELECT a,b,c FROM t1 UNION SELECT a,b,c FROM t2 UNION SELECT a,b,c FROM t3 UNION SELECT a,b,c FROM t4; -- ❌ 4个分支可读性差调试困难正确示范WITH src_t1 AS (SELECT a,b,c, T1 AS src FROM t1), src_t2 AS (SELECT a,b,c, T2 AS src FROM t2), src_t3 AS (SELECT a,b,c, T3 AS src FROM t3), src_t4 AS (SELECT a,b,c, T4 AS src FROM t4) SELECT a,b,c,src FROM src_t1 UNION SELECT a,b,c,src FROM src_t2 UNION SELECT a,b,c,src FROM src_t3 UNION SELECT a,b,c,src FROM src_t4;故障案例某物流调度系统一个UNION有7个分支对应7个区域仓库SQL长达200行。某次上线后性能暴跌DBA查执行计划发现优化器为7个分支生成了7套不同的访问路径且相互干扰。用WITH重构后优化器能统一估算基数执行时间稳定在0.5秒内。UNION分支越多优化器越迷茫。用WITH给它指条明路。4.6 铁律六UNION必须配合USE_NL或USE_HASH提示根据数据量选择规则当UNION结果集要与其他大表JOIN时必须在UNION外层加/* USE_NL(t_union t_other) */或/* USE_HASH(t_union t_other) */提示禁止依赖CBO自动选择。原因UNION产生的内联视图VW_NSO_1没有统计信息CBO无法准确估算其行数极易选错连接算法。正确示范SELECT /* USE_HASH(v u) */ v.id, v.name, u.status FROM ( SELECT id, name FROM t_a UNION SELECT id, name FROM t_b ) v JOIN t_user u ON v.id u.user_id;故障案例某在线教育平台课程查询UNION结果约2万行与用户表500万行JOINCBO误判UNION结果只有100行选择了NESTED LOOPS导致500万次单行查找耗时11分钟。加USE_HASH后改用哈希连接耗时降至1.2秒。UNION是黑盒你得亲手告诉优化器怎么打开它。4.7 铁律七所有UNION必须有对应的UNION ALL备份脚本上线前必须压测对比规则每个含UNION的SQL必须配套一个UNION ALL版本的脚本上线前在测试库用相同数据集压测记录执行时间、逻辑一致性、结果集行数差异。执行清单[ ]UNION脚本执行时间______s[ ]UNION ALL脚本执行时间______s[ ]UNION ALL结果行数______[ ]UNION结果行数______[ ] 行数差异是否符合业务预期□ 是 □ 否说明_________[ ] 差异行是否可人工验证□ 是 □ 否故障案例某政府服务平台一个UNION报表上线后市民投诉“查不到自己的办件记录”。压测对比发现UNION ALL返回1200条UNION返回1197条缺失3条。人工核查发现这3条是同一市民在不同渠道提交的相同申请业务规则要求只显示最新一条。UNION随机保留了一条但没按时间戳排序导致显示的不是最新记录。最终方案UNION ALL 外层ROW_NUMBER() OVER (PARTITION BY citizen_id ORDER BY submit_time DESC)取最新。UNION的“随机去重”不是bug是feature。但业务需要的从来不是随机而是确定性。5. 终极思考UNION的本质是妥协的艺术写完这篇我重新翻了Oracle SQL Language Reference里关于UNION的章节。官方定义冷静克制“UNIONreturns all distinct rows selected by either query.” 就这么一句。但现实远比定义残酷。我在某次架构评审会上听一位CTO说“我们不用UNION因为它的语义太弱——它只保证‘不重复’却不保证‘哪一条留下’。在分布式系统里这种不确定性就是灾难。”这句话点醒了我。UNION不是为了解决“如何合并”而是为了解决“如何在不确定中达成最低限度的一致”。它诞生于关系代数对集合的朴素信仰却在现代OLTP/OLAP混合场景中频频水土不服。所以真正的高手不是把UNION用得多溜而是在写第一个UNION之前就问清楚三个问题这个“去重”是数据层面的客观事实比如主键冲突还是业务层面的主观规则比如“同一客户只显示最新订单”如果去掉UNION用UNION ALL应用层处理整体链路是否更短、更可控、更易监控当这张UNION查询被嵌套在5层视图里被10个报表引用被3个微服务调用时它的每一次执行是否还能被一个人完整追踪、解释、优化我见过太多团队把UNION当胶水粘起一堆本不该在一起的表把UNION当缓存掩盖ETL流程的缺陷把UNION当权限开关用WHERE条件控制分支可见性……最后系统越来越重SQL越来越难懂问题越来越难查。所以这篇的结尾我不想给你一个“最佳实践清单”只想分享一个我坚持了十年的习惯每次写UNION我都先写一个UNION ALL版本运行它看结果。如果UNION ALL的结果里那些“重复行”在业务上本就不该存在——说明数据质量有问题该修源头如果UNION ALL的结果里“重复行”是合理的只是展示时需要去重——说明UNION是正确选择但必须加来源标识如果UNION ALL的结果行数和UNION一样多——恭喜你其实根本不需要UNION删掉它世界会清静很多。UNION不是终点而是你开始思考数据本质的起点。
