MySQL查询去重用UNION还是DISTINCT

前言

在日常开发中，数据去重是数据库操作中常见的需求，许多开发者常纠结于两种方案的选择：

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

不少开发者对 UNION 与 UNION ALL 的差异理解不够深入，经常误用，导致数据库性能白白损耗。

本文将从原理、适用场景、性能差距等多个维度进行对比分析，最后给出线上环境选型的标准实践方案。

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

1. DISTINCT

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

SELECT DISTINCT user_id FROM `user_login_log` WHERE `date` = CURDATE();

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

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

-- UNION：合并结果 + 自动去重 + 排序
SELECT user_id FROM `user` WHERE status = 1
UNION
SELECT user_id FROM `app_key` WHERE status = 1;

-- UNION ALL：仅简单纵向拼接，**不去重、不排序**
SELECT user_id FROM `user` WHERE status = 1
UNION ALL
SELECT user_id FROM `app_key` WHERE status = 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，同一用户的多条登录记录只展示一次。

-- 正确写法
SELECT DISTINCT user_id FROM user_login_log WHERE `date` = CURDATE();

-- ❌ 错误示范，没必要强行拆分UNION
SELECT user_id FROM user_login_log WHERE `date` = CURDATE()
UNION
SELECT user_id FROM user_login_log WHERE `date` = CURDATE();

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

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

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

方案A：UNION

SELECT user_id FROM `user` WHERE username = 'demo'
UNION
SELECT user_id FROM `app_key` WHERE access_key = 'demo_key';

方案B：UNION ALL + 外层DISTINCT

SELECT DISTINCT user_id FROM (
    SELECT user_id FROM `user` WHERE username = 'demo'
    UNION ALL
    SELECT user_id FROM `app_key` WHERE access_key = 'demo_key'
) t;

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

绝大多数情况下：UNION ALL + 外层DISTINCT 性能 ≥ UNION

原因：

UNION默认会附带排序操作；

而外层DISTINCT优化器可以选择哈希去重，不一定强制排序，优化空间更大。

追求稳定高性能，推荐统一使用 UNION ALL + DISTINCT 写法，避免UNION隐性排序带来的额外开销。

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

直接使用 UNION ALL，不要用UNION，也不要额外加DISTINCT。

省去全局比较、排序、去重带来的巨大开销。

SELECT id FROM `user` LIMIT 100
UNION ALL
SELECT id FROM `app_key` LIMIT 100;

五、高频误区汇总

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

不能替换。

DISTINCT作用于单查询内部；

UNION作用于多条查询合并之后，适用场景边界完全不同。

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

恰恰相反。

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

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

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

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

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

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

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

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

UNION ALL拆分多条查询时，每条子查询务必保证能正常命中索引；

如果最终只需要获取第一条匹配记录，可以在每层子查询增加 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：

-- 最优写法
SELECT DISTINCT user_id FROM (
    SELECT user_id FROM `user` WHERE username = 'demo'
    UNION ALL
    SELECT user_id FROM `user` WHERE email = 'demo@test.com'
    UNION ALL
    SELECT user_id FROM `app_key` WHERE access_key = 'demo_key'
) tmp;

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