MySQL DISTINCT 去重的几种方法使用

更新时间：2026年06月21日 09:33:43 作者：乱码字符

本文主要介绍了MySQL DISTINCT 去重的几种方法使用,重点讲解了两种去重算法临时表去重与索引去重和使用临时表,通过优化索引、使用覆盖索引或使用GROUPBY代替DISTINCT等种方法,可以显著提升查询性能

DISTINCT 是啥？

DISTINCT 用于去重（去掉重复行）。

基本用法

-- 统计不重复的用户数
SELECT DISTINCT user_id FROM orders;

问题：如果 orders 表有 2000 万行，user_id 有很多重复值，DISTINCT 要扫描 2000 万行，还要去重，很慢。

DISTINCT 的两种算法

MySQL 的 DISTINCT 有两种算法：临时表去重和索引去重。

1. 临时表去重（慢！）

如果 DISTINCT 的字段没索引，MySQL 会先把所有行放到临时表里，再对临时表去重。

执行流程

1. 扫描所有行 → 放到临时表
2. 2. 对临时表去重 → 返回结果
3. ```
**问题**：
4. 要扫描所有行（可能全表扫描）
5. 2. 要用临时表（可能写到磁盘）
#### 验证一下

```sql
-- user_id 没有索引
EXPLAIN SELECT DISTINCT user_id FROM orders;

输出：

+----+-------------+--------+------+---------------+------+---------+------+----------+----------------+
| id | select_type | table  | type | possible_keys | key  | key_len | ref  | rows     | Extra          |
+----+-------------+--------+------+---------------+------+---------+------+----------+----------------+
|  1 | SIMPLE      | orders | ALL  | NULL          | NULL | NULL    | NULL | 20000000 | Using temporary |
+----+-------------+--------+------+---------------+------+---------+------+----------+----------------+

问题：

type = ALL（全表扫描）
1. Extra = Using temporary（用临时表）

2. 索引去重（快！）

如果 DISTINCT 的字段有索引，MySQL 可以利用索引的有序性去重，不需要临时表。

原理

索引是有序的（B+ 树），相同的值会挨在一起。MySQL 只需要顺序扫描索引，遇到相同的就跳过，不需要临时表。

索引：user_id
[1, 1, 1, 2, 2, 3, 3, 3, ...]

扫描去重：
1 → 跳过相同的 1, 1
2 → 跳过相同的 2
3 → 跳过相同的 3, 3
...

验证一下

-- 给 user_id 加索引
CREATE INDEX idx_user_id ON orders(user_id);

EXPLAIN SELECT DISTINCT user_id FROM orders;

输出：

+----+-------------+--------+-------+---------------+-----------------+---------+------+----------+-------+
| id | select_type | table  | type  | possible_keys | key             | key_len | ref  | rows     | Extra |
+----+-------------+--------+-------+---------------+-----------------+---------+------+----------+-------+
|  1 | SIMPLE      | orders | index | NULL          | idx_user_id     | 5       | NULL | 20000000 |       |
+----+-------------+--------+-------+---------------+-----------------+---------+------+----------+-------+

优化效果：

type = index（索引扫描）
1. Extra 里没有 Using temporary 了（走索引去重，不需要临时表）
1. 执行时间从 30 秒降到 0.1 秒（300 倍提升！）

DISTINCT 的坑：临时表

DISTINCT 最大的坑是临时表。

什么时候会用临时表？

DISTINCT 的字段没索引

DISTINCT 和 ORDER BY 的字段不一样
DISTINCT 和 GROUP BY 混用

坑 1：DISTINCT 的字段没索引

-- user_id 没有索引
SELECT DISTINCT user_id FROM orders;  -- Using temporary

解决方案：给 DISTINCT 的字段加索引。

CREATE INDEX idx_user_id ON orders(user_id);
SELECT DISTINCT user_id FROM orders;  -- 没有 Using temporary

坑 2：DISTINCT 和 ORDER BY 的字段不一样

-- user_id 有索引，但 ORDER BY created_at
SELECT DISTINCT user_id FROM orders ORDER BY created_at;  -- Using temporary

问题：DISTINCT 要走 user_id 的索引，但 ORDER BY 要走 created_at 的索引，矛盾，只能用临时表。

解决方案：要么都走 user_id 的索引，要么都走 created_at 的索引。

-- 优化后：DISTINCT 和 ORDER BY 都用 user_id 的索引
SELECT DISTINCT user_id FROM orders ORDER BY user_id;  -- 没有 Using temporary

坑 3：DISTINCT 和 GROUP BY 混用

-- DISTINCT 和 GROUP BY 混用，用临时表
SELECT DISTINCT user_id, COUNT(*) FROM orders GROUP BY user_id;  -- Using temporary

问题：DISTINCT 和 GROUP BY 功能重复，MySQL 不知道用哪个，只能用临时表。

解决方案：去掉 DISTINCT（GROUP BY 已经去重了）。

-- 优化后：去掉 DISTINCT
SELECT user_id, COUNT(*) FROM orders GROUP BY user_id;  -- 没有 Using temporary

优化方案 1：给 DISTINCT 的字段加索引（推荐！）

思路：让 DISTINCT 走索引去重，避免临时表。

优化前

-- user_id 没有索引
SELECT DISTINCT user_id FROM orders;  -- 执行 30 秒（Using temporary）

优化后

-- 给 user_id 加索引
CREATE INDEX idx_user_id ON orders(user_id);

SELECT DISTINCT user_id FROM orders;  -- 执行 0.1 秒（没有 Using temporary）

优化效果：执行时间从 30 秒降到 0.1 秒（300 倍提升！）

优化方案 2：用覆盖索引

思路：如果查询的字段都在索引里，不需要回表，性能更好。

优化前

-- 查询所有字段，要回表
SELECT DISTINCT * FROM orders;  -- 执行 30 秒

优化后

-- 查询的字段都在索引里，不需要回表
SELECT DISTINCT user_id FROM orders;  -- 执行 0.1 秒

优化效果：不需要回表，性能提升 10 倍。

优化方案 3：用 GROUP BY 代替 DISTINCT

思路：GROUP BY 也会去重，但可以用索引，性能可能更好。

优化前

-- DISTINCT 可能用临时表
SELECT DISTINCT user_id FROM orders;  -- Using temporary

优化后

-- GROUP BY 可以用索引
SELECT user_id FROM orders GROUP BY user_id;  -- 没有 Using temporary

为什么？ GROUP BY 的优化比 DISTINCT 更成熟，更容易走索引。

优化方案 4：用 WHERE 限制范围

思路：如果 WHERE 条件能过滤掉大部分行，去重的行数就少了，性能更好。

优化前

-- 没有 WHERE，要去重 2000 万行
SELECT DISTINCT user_id FROM orders;  -- 执行 30 秒

优化后

-- 用 WHERE 限制范围，只去重 100 万行
SELECT DISTINCT user_id FROM orders WHERE created_at > '2024-01-01';  -- 执行 1 秒

优化效果：要去重的行数从 2000 万降到 100 万，性能提升 30 倍。

优化方案 5：用汇总表

思路：建一张汇总表，定期更新（比如每小时更新一次），查询时直接读汇总表。

第 1 步：建汇总表

CREATE TABLE user_order_count (
    user_id INT PRIMARY KEY,
        order_count INT NOT NULL,
            updated_at DATETIME NOT NULL
            );
            ```
### 第 2 步：初始化汇总表

```sql
INSERT INTO user_order_count (user_id, order_count, updated_at)
SELECT user_id, COUNT(*), NOW() FROM orders GROUP BY user_id;

第 3 步：定时更新汇总表

用定时任务（比如 cron、MySQL 事件）定期更新：

-- MySQL 事件：每小时更新一次
CREATE EVENT update_user_order_count
ON SCHEDULE EVERY 1 HOUR
DO
    TRUNCATE user_order_count;
        INSERT INTO user_order_count (user_id, order_count, updated_at)
            SELECT user_id, COUNT(*), NOW() FROM orders GROUP BY user_id;
            ```
### 第 4 步：查询时直接读汇总表

```sql
SELECT COUNT(DISTINCT user_id) FROM user_order_count;  -- 0.001 秒

优化效果：执行时间从 30 秒降到 0.001 秒（30000 倍提升！）

实战：优化一个慢 DISTINCT

假设有个订单表，要统计不重复的用户数，很慢：

SELECT COUNT(DISTINCT user_id) FROM orders;  -- 执行 30 秒

第 1 步：看执行计划

EXPLAIN SELECT COUNT(DISTINCT user_id) FROM orders;

输出：

+----+-------------+--------+------+---------------+------+---------+------+----------+----------------+
| id | select_type | table  | type | possible_keys | key  | key_len | ref  | rows     | Extra          |
+----+-------------+--------+------+---------------+------+---------+------+----------+----------------+
|  1 | SIMPLE      | orders | ALL  | NULL          | NULL | NULL    | NULL | 20000000 | Using temporary |
+----+-------------+--------+------+---------------+------+---------+------+----------+----------------+

问题：

type = ALL（全表扫描）
Extra = Using temporary（用临时表）

第 2 步：给 DISTINCT 的字段加索引

CREATE INDEX idx_user_id ON orders(user_id);

再看执行计划：

EXPLAIN SELECT COUNT(DISTINCT user_id) FROM orders;

输出：

+----+-------------+--------+-------+---------------+-----------------+---------+------+----------+-------+
| id | select_type | table  | type  | possible_keys | key             | key_len | ref  | rows     | Extra |
+----+-------------+--------+-------+---------------+-----------------+---------+------+----------+-------+
|  1 | SIMPLE      | orders | index | NULL          | idx_user_id     | 5       | NULL | 20000000 |       |
+----+-------------+--------+-------+---------------+-----------------+---------+------+----------+-------+

优化效果：

type = index（索引扫描）
Extra 里没有 Using temporary 了（走索引去重，不需要临时表）
执行时间从 30 秒降到 0.1 秒（300 倍提升！）

实战建议

1. 给 DISTINCT 的字段加索引（最重要！）

这是最重要的建议。DISTINCT 的字段没索引，绝对会用临时表，性能炸裂。

-- 优化前：没索引
SELECT DISTINCT user_id FROM orders;  -- Using temporary

-- 优化后：加索引
CREATE INDEX idx_user_id ON orders(user_id);
SELECT DISTINCT user_id FROM orders;  -- 没有 Using temporary

2. DISTINCT 和 ORDER BY 的字段要一样

如果 DISTINCT 和 ORDER BY 的字段不一样，会用临时表。

-- 优化前：字段不一样
SELECT DISTINCT user_id FROM orders ORDER BY created_at;  -- Using temporary

-- 优化后：字段一样
SELECT DISTINCT user_id FROM orders ORDER BY user_id;  -- 没有 Using temporary

3. 不要 DISTINCT 和 GROUP BY 混用

DISTINCT 和 GROUP BY 功能重复，混用会用临时表。

-- 优化前：混用
SELECT DISTINCT user_id, COUNT(*) FROM orders GROUP BY user_id;  -- Using temporary

-- 优化后：去掉 DISTINCT
SELECT user_id, COUNT(*) FROM orders GROUP BY user_id;  -- 没有 Using temporary

4. 用 WHERE 限制范围

如果 WHERE 条件能过滤掉大部分行，去重的行数就少了，性能更好。

-- 优化前：没有 WHERE
SELECT DISTINCT user_id FROM orders;  -- 执行 30 秒

-- 优化后：用 WHERE 限制范围
SELECT DISTINCT user_id FROM orders WHERE created_at > '2024-01-01';  -- 执行 1 秒

5. 用汇总表（对实时性要求不高）

如果可以接受数据滞后，用汇总表，性能炸裂。

-- 直接读汇总表
SELECT COUNT(DISTINCT user_id) FROM user_order_count;  -- 0.001 秒

总结

DISTINCT 去重的两种算法：临时表去重（慢）、索引去重（快）

DISTINCT 的坑：临时表（DISTINCT 的字段没索引、DISTINCT 和 ORDER BY 的字段不一样、DISTINCT 和 GROUP BY 混用）
优化方案 1：给 DISTINCT 的字段加索引（推荐！）
优化方案 2：用覆盖索引
优化方案 3：用 GROUP BY 代替 DISTINCT
优化方案 4：用 WHERE 限制范围
优化方案 5：用汇总表（对实时性要求不高）

实战建议：给 DISTINCT 的字段加索引、DISTINCT 和 ORDER BY 的字段要一样、不要 DISTINCT 和 GROUP BY 混用、用 WHERE 限制范围、用汇总表
如果你能把 DISTINCT 的两种算法、临时表的坑、5 种优化方案讲清楚，面试官绝对觉得你有实战经验。

实战代码都在我本地跑过，你可以放心复制。

到此这篇关于MySQL DISTINCT 去重的几种方法使用的文章就介绍到这了,更多相关MySQL DISTINCT 去重内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

您可能感兴趣的文章:

Ubuntu 18.04安装mysql 5.7.23
这篇文章主要为大家详细介绍了Ubuntu 18.04安装mysql 5.7.23的相关资料，具有一定的参考价值，感兴趣的小伙伴们可以参考一下
2019-02-02
MySQL数据库中正则表达式(Regex)和like的区别详析
MySQL正则表达式是一种强大的文本匹配工具,允许执行复杂的字符串搜索和处理,这篇文章主要介绍了MySQL数据库中正则表达式(Regex)和like区别的相关资料,文中通过代码需要的朋友可以参考下
2025-11-11
MySQL系列之六用户与授权
做为Mysql数据库管理员管理用户账户,是一件很重要的事,指出哪个用户可以连接服务器,从哪里连接,连接后能做什么,这篇文章主要介绍了MySQL用户与授权的相关资料,需要的朋友可以参考下
2021-07-07
mysql备份的三种方式详解
备份的本质就是将数据集另存一个副本，但是原数据会不停的发生变化，所以利用备份只能回复到数据变化之前的数据。那变化之后的呢？所以制定一个好的备份策略很重要
2013-09-09
分页技术原理与实现之分页的意义及方法（一）
这篇文章主要介绍了分页技术原理与实现第一篇：为什么要进行分页及怎么分页，感兴趣的小伙伴们可以参考一下
2016-06-06
Last_Errno: 1062，Last_Error: Error Duplicate entry
Last_Errno: 1062，Last_Error: Error Duplicate entry ... for key PRIMARY
2014-02-02
mysql中字段类型转义方式
这篇文章主要介绍了mysql中字段类型转义方式,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教
2023-12-12
SQL实现LeetCode(180.连续的数字)
这篇文章主要介绍了SQL实现LeetCode(180.连续的数字),本篇文章通过简要的案例,讲解了该项技术的了解与使用,以下就是详细内容,需要的朋友可以参考下
2021-08-08
mysql迁移达梦列长度超出定义的简单解决方法
这篇文章主要介绍了mysql迁移达梦列长度超出定义解决方法的相关资料,,在达梦数据库中,字符串长度的存储方式与MySQL不同,导致迁移过程中出现数据长度不足的错误,解决方法包括在MySQL中将varchar类型修改为varchar(10char)以强制字符存储,需要的朋友可以参考下
2024-12-12
Mysql多层子查询示例代码(收藏夹案例)
这篇文章主要介绍了Mysql多层子查询示例代码，以收藏夹案例给大家详细介绍，代码简单易懂，对大家的学习或工作具有一定的参考借鉴价值,需要的朋友可以参考下
2022-03-03