当前位置： 首页 > news >正文

UNION vs UNION ALL：去重机制与执行计划性能差异详解

news 2026/5/26 6:20:29

1. 为什么我花整整三天重写这组SQL查询——从 UNION 到 UNION ALL 的真实代价

在上个月给一家电商客户做订单数据清洗时，我遇到一个看似简单却差点让整套报表延迟上线的问题：一张合并了2022–2024三年销售明细的视图，执行耗时从1.8秒突然飙升到47秒，而SQL本身只改了一行——把UNION ALL换成了UNION。DBA发来执行计划截图时，我盯着那条红色高亮的Hash Aggregate节点看了足足五分钟。那一刻我才真正意识到：UNION 和 UNION ALL 不是“去重”和“不去重”的语义差别，而是两种完全不同的数据处理范式——前者是集合运算，后者是物理拼接；前者要排序、去重、归并，后者只是把内存里的两块数据头尾相接。这个认知偏差，让我在三年前刚转数据分析岗时就踩过坑：用 UNION 合并百万级日志表，本地测试跑通了，上线后直接把生产库的 tempdb 空间打爆。今天这篇，不讲教科书定义，不列干巴巴的语法，我就用你每天真实会遇到的场景、真实会看到的执行计划、真实会收到的告警截图，把 UNION 和 UNION ALL 的底层逻辑、选型依据、避坑细节，掰开揉碎讲清楚。如果你常写报表SQL、做ETL调度、维护数据看板，或者正被“为什么加个ALL就快十倍”这类问题困扰——这篇文章就是为你写的。核心关键词全在这里：SQL去重机制、结果集合并、执行计划优化、临时表空间、列对齐规则、NULL值处理、跨年数据聚合、分页性能陷阱。它不是理论课，而是一份我压箱底的SQL操作手册。

2. UNION vs UNION ALL：不只是“去重”二字能概括的底层逻辑

2.1 从数据库引擎视角看：它们根本不是同一种操作

很多初学者以为UNION就是UNION ALL+DISTINCT，这个理解在逻辑层勉强成立，但在物理执行层面完全错误。我拿 PostgreSQL 15 和 SQL Server 2022 做了对比实验（环境：AWS r6i.2xlarge，16GB内存，SSD存储），用同一组100万行测试数据跑相同逻辑：

-- 测试数据生成（简化版） CREATE TABLE sales_2023 AS SELECT generate_series(1,500000) as order_id, '2023-' || lpad((random()*1000)::text,3,'0') as sku, (random()*10000)::numeric(10,2) as amount; CREATE TABLE sales_2024 AS SELECT generate_series(1,500000) as order_id, '2024-' || lpad((random()*1000)::text,3,'0') as sku, (random()*10000)::numeric(10,2) as amount;

执行SELECT * FROM sales_2023 UNION ALL SELECT * FROM sales_2024时，PostgreSQL 的执行计划显示：

Append (cost=0.00..12450.00 rows=1000000 width=20) -> Seq Scan on sales_2023 (cost=0.00..6225.00 rows=500000 width=20) -> Seq Scan on sales_2024 (cost=0.00..6225.00 rows=500000 width=20)

注意关键词：Append。这是最轻量级的操作——引擎只是把两个扫描结果的内存地址指针记下来，等最终输出时按顺序读取。没有排序，没有哈希，没有临时磁盘IO。

而执行SELECT * FROM sales_2023 UNION SELECT * FROM sales_2024时，执行计划变成：

Unique (cost=24900.00..27400.00 rows=999999 width=20) -> Sort (cost=24900.00..26150.00 rows=1000000 width=20) Sort Key: sales_2023.order_id, sales_2023.sku, sales_2023.amount -> Append (cost=0.00..12450.00 rows=1000000 width=20) -> Seq Scan on sales_2023 (cost=0.00..6225.00 rows=500000 width=20) -> Seq Scan on sales_2024 (cost=0.00..6225.00 rows=500000 width=20)

这里出现了三个关键节点：Append → Sort → Unique。引擎必须先做物理拼接（Append），再对全部100万行数据按所有列排序（Sort），最后逐行比对相邻行是否完全一致（Unique）。排序阶段会触发大量内存分配，当内存不足时（默认work_mem=4MB），就会把中间结果写入磁盘临时文件——这就是为什么你看到执行时间从毫秒级跳到秒级。我在SQL Server上抓取的等待事件也印证了这点：UNION ALL主要等待PAGEIOLATCH_SH（页面读取），而UNION高频出现SORT_PAGE_REQUEST和TEMPDB_PAGE_ALLOC。

提示：不要迷信“数据库会自动优化”。即使两表完全没有重复数据，UNION依然会强制执行完整排序去重流程。它不会先检查“是否有重复”，而是无条件执行去重逻辑。

2.2 数学本质差异：集合论 vs 序列拼接

UNION的设计哲学来自集合论（Set Theory）：它把每个SELECT结果视为一个数学集合，而集合的定义就是“无序、无重复的元素集合”。因此UNION的结果必须满足集合的三大公理：

  • 确定性：相同输入必得相同输出（所以必须去重）
  • 互异性：同一元素不能出现两次（所以必须剔除重复）
  • 无序性：结果不保证原始顺序（所以需要显式ORDER BY）

而UNION ALL的本质是序列拼接（Sequence Concatenation）：它把每个SELECT结果视为一个有序列表，操作就是把列表B接到列表A末尾。它不关心内容是否重复，不改变原有顺序，也不要求元素可比较。这解释了为什么UNION ALL能保留原始查询的ORDER BY（虽然标准SQL不保证，但多数引擎会维持子查询顺序），而UNION必须丢弃所有子查询的排序，因为集合本身无序。

这个差异直接导致一个反直觉现象：当你需要“按时间倒序取最新10条记录”时，用UNION ALL+ 子查询排序，往往比UNION+ 全局排序更高效。我在处理用户行为日志时就用过这个技巧：

-- 错误示范：UNION后全局排序（扫描全部数据） (SELECT * FROM user_log_2023 ORDER BY event_time DESC LIMIT 10) UNION (SELECT * FROM user_log_2024 ORDER BY event_time DESC LIMIT 10) ORDER BY event_time DESC LIMIT 10; -- 正确实践：UNION ALL + 全局取TopN（只扫描20行） (SELECT * FROM user_log_2023 ORDER BY event_time DESC LIMIT 10) UNION ALL (SELECT * FROM user_log_2024 ORDER BY event_time DESC LIMIT 10) ORDER BY event_time DESC LIMIT 10;

前者会先合并两表全部数据（可能千万行），再排序取Top10；后者每个子查询只取10行，合并后仅20行参与最终排序。实测在10亿行日志表上，性能差距达237倍。

2.3 性能影响因子拆解：什么情况下差距会放大？

很多人问“数据量多大时该换用 UNION ALL？”，答案不是看行数，而是看四个维度的组合效应：

影响因子UNION 受影响程度UNION ALL 受影响程度实测案例（100万行）
列数量高（排序键增多，CPU消耗指数级上升）无（仅增加内存拷贝量）3列→10列：UNION耗时+320%，UNION ALL+12%
数据类型极高（字符串/JSON排序远慢于INT）低（只影响内存带宽）VARCHAR(200)字段：UNION慢4.7倍
重复率中（重复率越高，去重收益越大，但排序成本不变）无（重复与否不影响）90%重复数据：UNION仍比UNION ALL慢3.2倍
内存压力极高（排序溢出到磁盘时性能断崖下跌）低（仅需线性内存）work_mem=2MB：UNION磁盘IO占比达68%

我在某金融客户项目中遇到过极端案例：他们用UNION合并12张月度交易表（每张200万行），其中包含TEXT类型的交易备注字段。当把UNION改为UNION ALL后，ETL任务从平均18分钟降到23秒——不是因为去重逻辑被跳过，而是避免了对12×200万行TEXT字段的全文排序。后来我们用pg_stat_progress_sort视图监控到，原查询在排序阶段产生了14GB临时文件。

3. 实操中的生死线：列对齐、类型转换与NULL陷阱

3.1 列对齐的魔鬼细节：为什么“看起来一样”反而最危险

UNION/UNION ALL要求“对应位置的列具有兼容的数据类型”，但这个“兼容”在不同数据库里有天壤之别。我整理了主流引擎的隐式转换规则：

数据库INT + VARCHARDATE + TIMESTAMPNUMERIC(10,2) + FLOATNULL处理
PostgreSQL拒绝（需显式CAST）自动转为TIMESTAMP拒绝（精度丢失风险）NULL与任何值比较都为UNKNOWN
SQL ServerVARCHAR转为INT（失败则报错）TIMESTAMP转为DATE（截断时间）FLOAT转为NUMERIC（四舍五入）NULL参与比较返回NULL
MySQL 8.0VARCHAR数字转为INT（'123abc'→123）自动扩展为DATETIMEFLOAT转为DECIMAL（精度损失）NULL与NULL相等（违反SQL标准）

这个差异导致一个经典故障：在MySQL开发环境用UNION合并订单表和退款表，order_id在订单表是INT，在退款表是VARCHAR('REF-123')，测试时因隐式转换没报错。上线到PostgreSQL后直接崩溃。解决方案不是改代码，而是用显式CAST统一类型：

-- 安全写法（适配所有引擎） SELECT CAST(order_id AS VARCHAR(20)) as id, amount, 'order' as type FROM orders UNION ALL SELECT CAST(refund_id AS VARCHAR(20)) as id, -amount, 'refund' as type FROM refunds;

注意：CAST比CONVERT更具移植性，且在大多数引擎中性能相当。永远不要依赖隐式转换——它像定时炸弹，只在环境切换时引爆。

3.2 NULL值的三重幻觉：你以为的相等，数据库说不

UNION的去重逻辑基于“行级全等比较”，而NULL在SQL中是个异类：NULL = NULL返回UNKNOWN而非TRUE。这意味着什么？看这个真实案例：

-- 表A：用户注册信息（部分邮箱为空） id | name | email ---|-------|---------- 1 | Alice | alice@x.com 2 | Bob | NULL -- 表B：用户更新信息（部分邮箱为空） id | name | email ---|-------|---------- 2 | Bob | NULL 3 | Eve | eve@y.com -- 执行 UNION SELECT * FROM table_a UNION SELECT * FROM table_b; -- 结果只有3行！Bob的NULL邮箱被当作重复行去除了？

实际上，标准SQL规定：UNION在比较含NULL的行时，会使用“NULL-safe equality”（空安全相等），即把两个NULL视为相等。但这个行为在MySQL 5.7之前不支持，PostgreSQL 10之前需要启用transform_null_equals参数。我在迁移一个老Oracle系统时就栽在这儿：Oracle默认用NVL(email, 'NULL_PLACEHOLDER')包装，而目标库PostgreSQL没配参数，导致本该去重的NULL行全部保留，报表用户数虚高37%。

解决方案有三层防御：

  1. 开发层：对可能为NULL的列，用COALESCE(col, '<<NULL>>')标准化（注意<<NULL>>要确保不与真实数据冲突）
  2. 建模层：在星型模型中，用代理键（Surrogate Key）替代自然键，NULL值由维度表统一处理
  3. 运维层：在ETL脚本开头添加检查SELECT COUNT(*) FROM (SELECT * FROM t1 UNION SELECT * FROM t2) t WHERE ...验证去重效果

3.3 ORDER BY的隐藏规则：为什么你的排序总失效

几乎所有新手都会犯这个错误：在UNION的子查询里加ORDER BY。比如想取每个部门薪资最高的员工：

-- 错误！语法错误（SQL Server/PostgreSQL报错，MySQL允许但结果不可靠） (SELECT TOP 1 * FROM emp WHERE dept='HR' ORDER BY salary DESC) UNION (SELECT TOP 1 * FROM emp WHERE dept='IT' ORDER BY salary DESC);

原因在于：UNION操作符的优先级高于ORDER BY，子查询的ORDER BY会被视为语法错误。正确做法是用派生表（Derived Table）或CTE：

-- 正确方案（推荐CTE，可读性好） WITH top_hr AS ( SELECT * FROM emp WHERE dept='HR' ORDER BY salary DESC LIMIT 1 ), top_it AS ( SELECT * FROM emp WHERE dept='IT' ORDER BY salary DESC LIMIT 1 ) SELECT * FROM top_hr UNION ALL SELECT * FROM top_it;

但这里有个更隐蔽的陷阱：当UNION结果集需要分页时，ORDER BY必须放在最外层，且必须配合LIMIT/OFFSET。我见过太多报表因这个失误导致数据错乱：

-- 危险！看似取第11-20条，实际取的是未排序的任意20条中的后10条 (SELECT * FROM t1 UNION SELECT * FROM t2 LIMIT 20 OFFSET 10); -- 安全！先合并再排序再分页 (SELECT * FROM t1 UNION SELECT * FROM t2) ORDER BY created_at DESC LIMIT 10 OFFSET 10;

实测在100万行数据上，错误写法的分页结果每次执行都不同，因为数据库不保证UNION的行序。

4. 场景化决策树：什么情况下必须用 UNION，什么情况下死守 UNION ALL

4.1 UNION 的不可替代场景：当业务逻辑要求“数学意义上的唯一”

不是所有去重都是为了性能优化，有些是业务铁律。我总结了四大刚性需求场景：

场景1：主数据整合（Master Data Management）
当合并来自CRM、ERP、客服系统的客户信息时，UNION是底线。例如：

-- 客户主数据视图（必须保证每个customer_id唯一） SELECT customer_id, name, email, 'CRM' as source FROM crm_customers UNION -- 强制去重，避免同一客户在多系统中被计为多人 SELECT customer_id, name, email, 'ERP' as source FROM erp_customers UNION SELECT customer_id, name, email, 'SUPPORT' as source FROM support_customers;

这里如果用UNION ALL，会导致客户分析报表中出现重复ID，RFM模型计算完全失真。我们曾因此发现某客户在CRM中叫"张三"，在ERP中叫"张小三"，在客服系统中叫"张先生"——UNION把这三个记录合并为一条，触发人工核查流程。

场景2：指标口径校验（Metric Reconciliation）
财务月报中，不同部门用不同口径统计营收，UNION可快速定位差异：

-- 检查各系统营收数据一致性 SELECT 'FINANCE_SYSTEM' as system, revenue_month, SUM(amount) as total FROM finance_revenue GROUP BY revenue_month UNION -- 关键：去重后只剩共同月份，缺失月份自动暴露 SELECT 'SALES_SYSTEM' as system, revenue_month, SUM(amount) as total FROM sales_revenue GROUP BY revenue_month;

结果中若某月份只出现一次，说明另一系统漏传数据；若出现两次但金额不同，则存在口径差异。这个技巧帮我们提前3天发现某次SAP升级导致的收入确认延迟。

场景3：动态权限过滤（Row-Level Security）
当用户可访问多张权限表时，UNION是实现“最小权限集”的最简方案：

-- 用户可见的订单列表（取其在任一权限表中的订单） SELECT order_id FROM orders WHERE order_id IN (SELECT order_id FROM user_orders_2023) UNION -- 确保同一订单不因跨权限表重复出现 SELECT order_id FROM orders WHERE order_id IN (SELECT order_id FROM user_orders_2024);

这里UNION不是为性能，而是为业务正确性——用户不该看到重复订单。

场景4：数据质量探查（Data Profiling）
用UNION快速识别脏数据模式：

-- 查找所有含特殊字符的邮箱（跨多张表） SELECT email FROM users WHERE email ~ '[^a-zA-Z0-9@._-]' UNION -- 去重后得到唯一问题邮箱列表，便于批量清洗 SELECT email FROM customers WHERE email ~ '[^a-zA-Z0-9@._-]' UNION SELECT email FROM leads WHERE email ~ '[^a-zA-Z0-9@._-]';

4.2 UNION ALL 的黄金场景：当你要的是“物理事实”，而非“数学抽象”

UNION ALL的核心价值在于零损耗地保留原始数据的物理形态。以下是五个高频应用：

场景1：时序数据追加（Time-Series Append）
日志、IoT传感器数据、交易流水，天然适合UNION ALL：

-- 查询最近30天所有设备心跳（保留每条原始记录） SELECT device_id, ts, status FROM heartbeats_20240501 UNION ALL SELECT device_id, ts, status FROM heartbeats_20240502 UNION ALL ... SELECT device_id, ts, status FROM heartbeats_20240530;

这里如果用UNION，会丢失同一设备在毫秒级间隔内的多次心跳，导致可用性计算错误。我们曾因此误判某批设备故障率偏高，实际是心跳频率过高触发了去重。

场景2：ETL中间表拼接（Staging Table Merge）
在数据仓库中，UNION ALL是构建ODS层的事实表基石：

-- 构建订单事实表（每日增量抽取） INSERT INTO fact_orders SELECT *, '20240501' as etl_date FROM staging_orders_20240501 UNION ALL SELECT *, '20240502' as etl_date FROM staging_orders_20240502 UNION ALL SELECT *, '20240503' as etl_date FROM staging_orders_20240503;

注意：这里etl_date字段是人工添加的分区标识，确保后续可按日期快速剪枝。UNION ALL保证每条原始记录100%进入事实表。

场景3：分页查询优化（Pagination Optimization）
当需要跨多张分表查询时，UNION ALL+ROW_NUMBER()是最优解：

-- 查询用户所有订单（订单按user_id哈希分表） WITH all_orders AS ( SELECT order_id, user_id, amount, create_time FROM orders_000 WHERE user_id = 123 UNION ALL SELECT order_id, user_id, amount, create_time FROM orders_001 WHERE user_id = 123 UNION ALL ... ) SELECT * FROM ( SELECT *, ROW_NUMBER() OVER (ORDER BY create_time DESC) as rn FROM all_orders ) t WHERE rn BETWEEN 11 AND 20;

相比UNION+ 全局排序，此方案减少90%的排序数据量。

场景4：实时流处理（Streaming Processing）
在Flink/Spark Structured Streaming中，UNION ALL对应union()API，是流合并的标准方式：

# PySpark中合并多个Kafka主题 df_2023 = spark.readStream.format("kafka").option("topic", "orders_2023")... df_2024 = spark.readStream.format("kafka").option("topic", "orders_2024")... combined_df = df_2023.union(df_2024) # 注意：PySpark的union等价于UNION ALL

这里绝不能用UNION，因为流数据没有“全局去重”概念，且会引入不可接受的延迟。

场景5：测试数据生成（Test Data Fabrication）
用UNION ALL快速构造边界测试数据：

-- 生成含各种NULL组合的测试数据 SELECT 1 as id, 'A' as name, NULL as email, 'active' as status UNION ALL SELECT 2 as id, NULL as name, 'b@x.com' as email, 'inactive' as status UNION ALL SELECT 3 as id, 'C' as name, 'c@x.com' as email, NULL as status;

5. 生产环境排障实录：那些让你半夜爬起来的 UNION 相关故障

5.1 故障1：tempdb 空间告警——UNION 排序溢出的连锁反应

现象：凌晨2点收到DBA电话，SQL Server tempdb使用率98%，所有报表作业卡死。
排查过程：

  1. 查sys.dm_db_task_space_usage发现TOP1耗尽空间的会话执行的是一个UNION查询
  2. 用DBCC OPENTRAN确认无长事务，排除锁阻塞
  3. 抓取该查询执行计划，发现Sort操作符的Actual Tempdb Space Used达12GB
  4. 检查查询：合并8张月度销售表，每张含NVARCHAR(4000)的备注字段

根因：UNION强制对8×50万行×4000字节=16GB原始数据排序，而服务器tempdb配置仅8GB，导致频繁磁盘交换。

解决方案：

  • 短期：调高tempdb文件大小，重启服务（治标）
  • 长期：改用UNION ALL+ 应用层去重（治本）
  • 架构层：将长文本字段移到单独的sales_notes表，主表只存note_id

实操心得：在SQL Server中，当Sort操作符的Estimated Row Size> 1KB 且Estimated Number of Rows> 10万时，必须警惕tempdb溢出风险。用SET STATISTICS XML ON可提前预判。

5.2 故障2：数据不一致——MySQL与PostgreSQL的NULL处理差异

现象：同一份ETL脚本在MySQL开发环境结果正确，在PostgreSQL生产环境用户数多出23%。
排查过程：

  1. 对比两环境UNION查询的执行计划，发现PostgreSQL多了HashAggregate节点
  2. 抽样检查多出的记录，全是email IS NULL的用户
  3. 查文档确认：MySQL 5.7默认开启ANSI_NULLS OFF，而PostgreSQL严格遵循SQL标准

根因：MySQL把NULL = NULL当作TRUE进行去重，PostgreSQL当作UNKNOWN跳过去重。

解决方案：

  • 统一用COALESCE(email, '<<NULL>>')替换所有可能为NULL的列
  • 在ETL脚本开头添加兼容性检查：
    -- 验证NULL处理一致性 SELECT COUNT(*) FROM ( SELECT COALESCE(email, '<<NULL>>') as e FROM users_2023 UNION SELECT COALESCE(email, '<<NULL>>') as e FROM users_2024 ) t;

5.3 故障3：分页错乱——ORDER BY 位置错误引发的雪崩

现象：用户反馈“我的订单列表第2页总是显示第1页的内容”。
排查过程：

  1. 复现问题：执行分页SQL，发现OFFSET 10 LIMIT 10返回的10条记录，与OFFSET 0 LIMIT 20的后10条不一致
  2. 检查SQL：发现ORDER BY写在了UNION子查询内
  3. 查执行计划：PostgreSQL对每个子查询单独排序，UNION合并后行序完全随机

根因：UNION操作符不保证子查询的排序顺序，合并后的结果集是无序的。

解决方案：

  • 强制要求所有分页查询的ORDER BY必须在最外层
  • 在CI/CD中加入SQL静态检查：用正则匹配(UNION|UNION ALL).*ORDER BY报警
  • 对关键报表，添加数据校验：SELECT COUNT(*) FROM (SELECT * FROM t1 UNION SELECT * FROM t2) t与SELECT COUNT(*) FROM t1)+COUNT(*) FROM t2)的差值应等于重复行数

5.4 故障4：隐式转换失败——跨数据库迁移的隐形杀手

现象：Oracle迁移到TiDB后，一个核心报表查询报错ERROR 1267 (HY000): Illegal mix of collations。
排查过程：

  1. 错误指向UNION操作，但两表结构完全一致
  2. 查SHOW CREATE TABLE发现：Oracle中VARCHAR2(100)默认用AL32UTF8，TiDB中VARCHAR(100)用utf8mb4_bin
  3. UNION要求列字符集完全一致，否则触发隐式转换失败

根因：UNION的类型检查比UNION ALL更严格，不仅检查数据类型，还检查字符集、排序规则（collation）。

解决方案：

  • 迁移前用脚本检查所有UNION查询涉及的列：
    SELECT column_name, data_type, character_set_name, collation_name FROM information_schema.columns WHERE table_name IN ('t1','t2') AND column_name = 'name';
  • 统一字符集：ALTER TABLE t1 CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
  • 在UNION查询中显式指定：SELECT name COLLATE utf8mb4_unicode_ci FROM t1 UNION SELECT name COLLATE utf8mb4_unicode_ci FROM t2;

6. 高阶技巧与未来演进：超越基础语法的实战智慧

6.1 用 CTE + WINDOW FUNCTION 替代复杂 UNION

当需要对UNION ALL结果做精细化去重时，ROW_NUMBER()比UNION更灵活：

-- 需求：合并多源用户数据，但优先取CRM数据，CRM缺失时取ERP WITH merged AS ( SELECT user_id, name, email, 'CRM' as source, 1 as priority FROM crm_users UNION ALL SELECT user_id, name, email, 'ERP' as source, 2 as priority FROM erp_users ), ranked AS ( SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY priority) as rn FROM merged ) SELECT user_id, name, email, source FROM ranked WHERE rn = 1; -- 每个user_id只取最高优先级的一条

这个方案的优势在于：

  • 可定义任意优先级逻辑（不局限于去重）
  • 可保留所有原始记录用于审计（rn > 1的记录可存入duplicate_log表）
  • 避免UNION的全量排序开销，只对分组内少量数据排序

6.2 分区表场景下的 UNION ALL 优化策略

在处理按时间分区的大表时，UNION ALL可结合分区裁剪（Partition Pruning）实现极致性能：

-- 假设 orders 表按 month 分区 -- 传统写法（无法裁剪） SELECT * FROM orders WHERE order_month BETWEEN '202401' AND '202403'; -- 优化写法（显式指定分区，100%裁剪） SELECT * FROM orders PARTITION (p202401) UNION ALL SELECT * FROM orders PARTITION (p202402) UNION ALL SELECT * FROM orders PARTITION (p202403);

实测在10TB订单表上，后者比前者快17倍，因为避免了全表扫描和分区元数据查找。注意：此写法需数据库支持显式分区引用（MySQL 5.7+, PostgreSQL 12+, Oracle 11g+）。

6.3 云原生时代的 UNION 演进：Materialized Views 与 Query Rewrite

现代云数据仓库（如Snowflake、BigQuery）已内置智能优化：

  • 自动重写：当检测到UNION查询中子查询无重叠数据时，自动转为UNION ALL
  • 物化视图加速：对高频UNION查询创建物化视图，预计算去重结果
  • Z-Order优化：在UNION ALL后的表上对常用JOIN键做Z-Order聚簇，提升后续关联性能

我们在Snowflake项目中实践过：对一个日均执行2000+次的UNION报表，创建物化视图后，P95延迟从8.2秒降至127毫秒。关键是设置正确的刷新策略：

-- Snowflake物化视图（自动增量刷新） CREATE MATERIALIZED VIEW mv_sales_union AS SELECT * FROM sales_2023 UNION SELECT * FROM sales_2024 UNION SELECT * FROM sales_2025; -- 刷新策略：ON CHANGE（数据变更时自动刷新）

6.4 终极建议：建立团队SQL规范清单

基于十年踩坑经验，我给团队制定了《UNION/UNION ALL 使用红线》：

  1. 默认禁用UNION：除非业务需求明确要求数学去重，否则一律用UNION ALL
  2. 强制显式CAST：所有UNION/UNION ALL查询，必须对每列做CAST(col AS target_type)
  3. NULL标准化前置：在ETL入口层，用COALESCE(col, '<<NULL>>')统一NULL表示
  4. 分页必加外层ORDER BY：CI检查项，未通过禁止上线
  5. 大表UNION必走分区：超过100万行的表，必须用PARTITION (p202401)显式引用
  6. 性能基线监控：对所有UNION查询，记录执行时间、tempdb使用量、排序内存占比，异常时自动告警

最后分享一个个人体会：刚工作时，我把UNION当作“高级功能”，总想用它显得专业；现在我把它看作“手术刀”——只在必须精确切除病灶时才动用。而UNION ALL是日常工具箱里的螺丝刀，可靠、高效、永不意外。真正的SQL高手，不是知道多少语法，而是清楚每一行代码在数据库引擎里激起怎样的波澜。下次当你敲下UNION时，不妨停顿三秒，问问自己：我真的需要数学意义上的唯一性，还是只是习惯了这种写法？

http://www.gsyq.cn/news/1387865.html

相关文章：

  • Excel簇状柱形图实战指南：多维离散数据对比可视化
  • 软件测试外包实战指南：独立团队、人员稳定与AI辅助的真相
  • 从ZIP解压到网络传输：深入浅出图解CRC-32校验的日常工作
  • Kali Linux下BurpSuite Pro完整部署与HTTPS抓包实战指南
  • AMD Ryzen 7 3800X + VMware 15.1.0 保姆级教程：手把手带你搞定macOS Catalina虚拟机（含避坑指南）
  • STC8单片机定时器中断里自增32位变量，为啥结果总出错？一个被忽略的8位机内存访问细节
  • 硬件在环(HIL)测试入门：如何用自制的60通道万能BOB盒搭建你的第一个汽车ECU测试台架？
  • CSS三大定位技巧全解析
  • 源代码论文分享｜基于Java的企业OA管理系统的设计与实现！
  • 别再为VTK+VS配置发愁了！手把手教你用CMake搞定VTK 9.0（附完整测试代码）
  • 实时系统中LLM异步集成：从500ms阻塞到零感知延迟的架构实践
  • DeepSeek注释生成准确率提升63.8%的关键突破（内部Benchmark白皮书首次流出）
  • 梯度提升原理与实战：从错误追击到工业级部署
  • C#原生鼠标录制回放：基于Raw Input的高精度Windows输入控制
  • 八年测试外包实战复盘：从人力输出到质量伙伴的转型之路
  • Unity平台游戏资源包：预校准物理-动画-音频协同开发流水线
  • 手把手教你用GEE APP玩转变化检测：Landtrendr、Bfast、CCDC官方可视化工具实操避坑
  • 从一次CAN总线‘丢帧’排查说起：深入理解扩展帧过滤器的‘列表模式’与‘掩码模式’到底怎么选
  • LizzieYzy：围棋AI分析的终极指南，3分钟快速入门
  • Excel频域分析实战：从振动信号到频谱图，5步教你诊断设备故障
  • AiScan‑N_Ai：轻量AI驱动的渗透侦察流水线
  • 构建高可用实时社交媒体事件总线：解耦、扩展与容错实践
  • Netty入门(hello world)
  • HyperMesh防崩溃神器：手把手教你配置自带的autosave.tcl脚本（附开机自启动教程）
  • 多智能体协同进化：AI驱动科学机器学习建模策略创新
  • AI代理成本优化：三分钟止血方案与长期降本策略
  • pad.ws：白板与代码编辑器合二为一的创新工具，打造无缝开发体验
  • redis-线程模型
  • Unity Animator深度解析：状态机原理与性能优化实战
  • AI智能体工程化实践：从模型调用到工具集成的四大构建方向