企业官网建设流程全解析

标签：MySQL、SQL优化、去重、UNION、DISTINCT、UNION ALL、执行计划

前言

开发过程中经常面临数据去重需求，大家常会纠结两种方案：

1. 使用DISTINCT在单条结果集中完成去重；
2. 使用UNION合并多条查询并自动去重。

还有很多开发者分不清UNION和UNION ALL的巨大差异，经常误用导致数据库出现不必要的性能消耗。
本文对比两者原理、适用场景、性能差距，给出线上环境选型标准。

一、先理清基础语法与核心行为

1. DISTINCT

作用：对单条SQL的结果集进行去重。

SELECTDISTINCTuser_idFROM`user_login_log`WHERE`date`=CURDATE();

执行逻辑：
数据库取出所有满足条件的数据，按照指定字段进行分组对比，剔除重复行，保留唯一记录。

2. UNION 与 UNION ALL（重点区分）

-- UNION：合并结果 + 自动去重 + 排序SELECTuser_idFROM`user`WHEREstatus=1UNIONSELECTuser_idFROM`app_key`WHEREstatus=1;-- UNION ALL：仅简单纵向拼接，**不去重、不排序**SELECTuser_idFROM`user`WHEREstatus=1UNIONALLSELECTuser_idFROM`app_key`WHEREstatus=1;

很多人踩坑：以为 UNION = UNION ALL，二者性能差距极大。
UNION = UNION ALL + DISTINCT + 排序操作

二、底层实现原理对比

DISTINCT 原理

在结果集内部构建临时内存哈希表或者排序缓冲区，遍历数据消除本行内重复记录。
数据量较小使用内存；数据量大超过缓冲区限制，则落地磁盘临时文件，性能断崖下跌。

UNION 原理

1. 分别执行前后两条子查询；
2. 使用UNION ALL把所有数据纵向汇总；
3. 全局执行一次DISTINCT排序去重。

简单公式：

UNION = UNION ALL + DISTINCT

三、核心性能结论

1. 如果业务需要合并多条SQL结果并且去重：可以使用UNION；
2. 如果多条SQL合并，原始数据不存在重复，优先使用UNION ALL，不要用 UNION；
3. 如果只是单表/单条查询内部去重，不要使用 UNION，直接使用DISTINCT；
4. 杜绝滥用 UNION 实现单条SQL内部去重，属于完全错误用法。

四、场景分类实战分析

场景1：单条查询内部去除重复数据 ✅ DISTINCT

需求：查询当日登录日志里所有活跃用户ID，同一用户多条登录记录只展示一次。

-- 正确写法SELECTDISTINCTuser_idFROMuser_login_logWHERE`date`=CURDATE();-- ❌ 错误示范，没必要强行拆分UNIONSELECTuser_idFROMuser_login_logWHERE`date`=CURDATE()UNIONSELECTuser_idFROMuser_login_logWHERE`date`=CURDATE();

强行使用UNION会执行两次相同查询，扫描双倍数据，额外执行全局去重，资源翻倍浪费。

场景2：多条独立查询结果合并，需要全局去重

需求：从用户表、密钥表两处查询user_id，合并结果，同一个user_id只保留一条。

方案A UNION

SELECTuser_idFROM`user`WHEREusername='demo'UNIONSELECTuser_idFROM`app_key`WHEREaccess_key='demo_key';

方案B UNION ALL + 外层DISTINCT

SELECTDISTINCTuser_idFROM(SELECTuser_idFROM`user`WHEREusername='demo'UNIONALLSELECTuser_idFROM`app_key`WHEREaccess_key='demo_key')t;

重点：方案A 和方案B哪个更快？

绝大多数情况下：UNION ALL + 外层DISTINCT 性能 ≥ UNION
原因：
UNION默认会附带排序行为；
而外层DISTINCT优化器可以选择哈希去重，不一定强制排序，优化空间更大。
追求稳定高性能，推荐统一使用UNION ALL + DISTINCT写法，避免UNION隐性排序带来开销。

场景3：多条查询合并，明确不存在重复数据

✅ 直接使用UNION ALL，不要使用UNION，不要额外加DISTINCT
省去全局比较、排序、去重的巨大开销。

SELECTidFROM`user`LIMIT100UNIONALLSELECTidFROM`app_key`LIMIT100;

五、高频误区汇总

误区1：UNION 和 DISTINCT 可以随意互相替换

❌ 不能替换。
DISTINCT作用于单查询内部；
UNION作用于多条查询合并之后，适用场景边界完全不同。

误区2：UNION去重性能优于 UNION ALL + DISTINCT

❌ 恰恰相反。
UNION强制执行排序去重；UNION ALL只做拼接，把去重选择权交给外层，优化器拥有更多优化策略。

误区3：少量数据，随便写无所谓

在测试环境少量数据看不出差距；当结果集上万、十万级别，UNION额外排序会直接引发慢查询，线上极易爆出性能故障。

误区4：不知道UNION自带排序，导致不必要的消耗

MySQL UNION规范：合并完成后会执行排序操作；如果你不需要排序，不要使用UNION。

六、索引层面额外优化提示

1. DISTINCT查询尽量建立覆盖索引，避免大量回表；

-- 示例：利用索引直接完成去重，无需读取原始数据表CREATEINDEXidx_date_userONuser_login_log(`date`,user_id);

2. UNION ALL拆分多条查询时，每条子查询务必保证可以正常命中索引；
3. 如果最终只需要获取第一条匹配记录，可以每层子查询增加 LIMIT 实现短路查询，减少扫描行数。

七、选型决策清单（线上直接套用）

1. 仅单条SQL内部去重→ 使用DISTINCT
2. 多条SQL结果合并，存在重复且需要去重→ 优先：UNION ALL + 外层DISTINCT
3. 多条SQL结果合并，确认无重复→ 使用UNION ALL
4. 禁止：单条查询场景强行拆分使用UNION做去重
5. 禁止：能用UNION ALL的场景随意使用UNION

八、验证手段

使用EXPLAIN观察执行计划：

• UNION：通常能看到Using temporary; Using filesort（临时表+文件排序）
• UNION ALL：没有全局排序与临时表，执行计划更加简洁

总结一句话：去重工具没有绝对好坏，分清场景再选择；能使用 UNION ALL 就不要使用 UNION，能避免全局排序就尽量避免。

延伸业务小案例（你项目常用场景）

根据账号、邮箱、密钥多条件检索用户ID：

-- 最优写法SELECTDISTINCTuser_idFROM(SELECTuser_idFROM`user`WHEREusername='demo'UNIONALLSELECTuser_idFROM`user`WHEREemail='demo@test.com'UNIONALLSELECTuser_idFROM`app_key`WHEREaccess_key='demo_key')tmp;

相比直接写三条UNION，性能更好，也是线上检索场景标准写法。