MySQL去重实测：distinct与group by性能差异及正确选择

上周代码评审，同事指着一行 SQL 问我：“这张表已经有两百多万条埋点记录了，现在要统计每天去重后的用户量，我到底是该用 distinct 还是 group by，网上答案怎么说什么的都有？”这个问题我几乎每隔几个月就会遇到一次。争论从 MySQL 5.6 时代延续到 8.0，甚至到 Spark、Hive 里还有人吵。我先给个可能反直觉的结论：如果只是“去重后把值列出来”，100W 行这个量级下，distinct 和 group by 的执行路径通常高度重合，性能差距远没有网上说的那么大。真正决定选哪个的，是你的查询意图、字段上有没有索引、以及你用的数据库版本里有哪些“历史包袱”。

这个题目很适合拿来当一次小型性能实验来做。我直接造了一张百万行的表，把两个写法都跑了一遍，也把代码评审里经常遇到的“去重计数”“每组取一条明细”这些衍生需求放进来看了一遍，整个过程里的几个坑还挺典型的，值得记录下来。

1. 先看执行计划：distinct和group by到底是哪一步分家的

1.1 两个SQL在优化器眼里的“翻译结果”不一样

先回到基础语义。select distinct user_id from t_user_event，这句话的意思是：把 user_id 这一列的所有值拿出来，去掉重复的，然后输出。而 select user_id from t_user_event group by user_id，在没带任何聚合函数时，意思是：按照 user_id 分组，每组只输出一个代表值。

看起来两个需求一样，但优化器理解它们的方式不同。distinct 在逻辑执行计划里更接近一个“去重算子”，group by 则是一个“分组聚合算子”。问题在于，MySQL 的实现里，如果 group by 后面没有聚合函数，它要做的事情本质上就是“把每个分组里随便挑一行出来”，在绝大多数情况下，这个动作和“去重”是等价的，执行路径也因此趋同。

我在 MySQL 8.0 上对两个 SQL 分别跑了 EXPLAIN，输出里都能看到 Using temporary。这说明引擎在没有好索引可用时，会把数据塞进临时表，然后通过临时表上的唯一索引或排序来完成去重/分组。优化器没有因为它们语义不同就给出天差地别的方案。

1.2 执行计划证据：几乎同源的临时表去重路径

我用的表结构不算复杂：

sql复制CREATE TABLE t_user_event (
  id bigint NOT NULL AUTO_INCREMENT,
  user_id int NOT NULL,
  event_type varchar(32) NOT NULL,
  event_time datetime NOT NULL,
  remark varchar(100) DEFAULT '',
  PRIMARY KEY (id),
  KEY idx_user_id (user_id)
) ENGINE=InnoDB;

在没有命中索引的情况下：

sql复制EXPLAIN SELECT DISTINCT user_id FROM t_user_event;
EXPLAIN SELECT user_id FROM t_user_event GROUP BY user_id;

两个执行计划在关键列上几乎一致，都是 type: ALL，也就是全表扫描，然后 Extra 里都有 Using temporary。区别只是在详细输出里，一个标注的是去重排序，另一个标注的是分组排序。

这个问题在 MySQL 8.0 里看得更清楚。8.0 支持 EXPLAIN ANALYZE，可以直接看到每一步的实际耗时。跑出来的结果里，两个 SQL 的时间消耗大头都落在“把 100W 行读出来，再往临时表里灌数据”这一步，真正的去重/分组动作占的时间非常小。所以如果你想优化一条“distinct 慢”的 SQL，把注意力放在“如何让引擎少读点数据”上，往往比纠结换成 group by 更有效。

1.3 MySQL 8.0 把 group by 的“隐藏排序福利”删了

不少人记忆里的结论是“group by 比 distinct 慢”，这个结论放在老版本里确实有可能成立，但原因不是 group by 本身更重，而是 MySQL 5.7 及更早版本里，GROUP BY 会默认按照分组列做一次隐式排序，而 DISTINCT 在某些情况下靠临时表配合唯一索引就能完成，不一定需要额外的 filesort。如果查询里还带着一个不小的结果集，group by 就多了一次排序成本。

MySQL 8.0 已经把 GROUP BY 的隐式排序移除了。除非你显式写 ORDER BY user_id，否则 engine 不再保证 group by 结果有序。这就导致两个后果：一是很多从 5.7 升到 8.0 的应用，发现原本“自动有序”的分页结果顺序变了，这是升级后很常见的翻车点；二是“group by 一定更慢”这个老经验在 8.0 里基本失效了。

所以讨论这个题之前，最好先确认对方用的哪个版本，不然很容易拿着旧版本的结论去套新版本的执行计划。

2. 100W行实测：加了索引你没感觉，没索引才是真正分水岭

2.1 造一张100W行的表，把变量控制住

为了把问题说清楚，我造了一张一百万行的表。这里有个容易踩的坑：直接用递归 CTE 插入随机数时，MySQL 8.0 对 RAND() 的行为有时候会让人意外，建议把生成逻辑先 SP 化，或者用数字序列再包一层计算，否则可能插入的数据分布不均匀。

我这里用了 30 万个不重复 user_id，平均每个 user_id 大约对应 3.3 条事件记录，这样既保留了重复数据，又不至于让某一个值过于倾斜。具体如下：

sql复制INSERT INTO t_user_event (user_id, event_type, event_time, remark)
WITH RECURSIVE seq(n) AS (
  SELECT 1 UNION ALL SELECT n + 1 FROM seq WHERE n < 1000000
)
SELECT
  FLOOR(RAND() * 300000) + 1,
  ELT(1 + FLOOR(RAND() * 5), 'click', 'view', 'buy', 'cart', 'share'),
  NOW() - INTERVAL FLOOR(RAND() * 365) DAY,
  CONCAT('remark_', n)
FROM seq;

实验环境是本地一台 16G 内存的机器，MySQL 8.0.33，InnoDB 引擎，SSD 磁盘。一百万行在这个配置下完全跑得动，跑出来的耗时不是绝对标准，但同机对比时相对差异很能说明问题。

2.2 无索引场景：两个SQL都在临时表里较劲

先故意不建 idx_user_id 索引，直接在百万行表上执行两个 SQL。为了避免缓存影响，我每次先用 SELECT SQL_NO_CACHE 或者通过重启连接来降低干扰，真实业务里百万行全扫描也会有类似表现。

sql复制SELECT DISTINCT user_id FROM t_user_event;
SELECT user_id FROM t_user_event GROUP BY user_id;

跑了三次，数据大致如下：

这个差异基本就是噪声。百万行全表扫一遍本来就要百毫秒级别，两者都要做临时表，差距非常小。真正让我意外的是，当我尝试把查询改成 SELECT DISTINCT user_id, event_type, remark 这种“带大字段去重”的写法时，查询时间直接跳到 1.5 秒以上，甚至逼近 2 秒。临时表里装的列变宽了，内存里放不下，就得往磁盘上写，这个代价远远超过 distinct 和 group by 本身的实现差异。

所以第一个经验先记住：没有索引时，判断两个关键字谁快没有太大意义，真正该关注的是临时表里到底塞了多宽的行。

2.3 有了索引之后，结果会让“关键字之争”显得很无聊

给 user_id 建上单列索引后，再跑：

sql复制CREATE INDEX idx_user_id ON t_user_event(user_id);

SELECT DISTINCT user_id FROM t_user_event;
SELECT user_id FROM t_user_event GROUP BY user_id;

两个 SQL 的执行计划都变成了 Using index，走的是覆盖索引扫描。InnoDB 索引本身已经把 user_id 排好序了，优化器在扫描过程中就能顺便消除重复，甚至不需要临时表和 filesort。

这次耗时都降到几十毫秒级别，distinct 和 group by 几乎没有可感知的差别。换句话说，只要查询列上有合适的索引，“distinct 快还是 group by 快”这个问题的技术含量就低了很多，因为两者都直接受益于索引的有序性。

如果是多列去重，比如 DISTINCT user_id, event_type，则需要一个联合索引 (user_id, event_type)，才能让两个列都命中覆盖扫描。只要查询里 select 出来的所有列都包含在某个索引中，去重压力就会大幅下降。

2.4 不同数据分布下的结果：低基数字段差异更小

我在造数时额外做了一组对照实验，把 user_id 改成只有 1 万个不重复值，也就是说平均每个用户有 100 条记录。这种情况下重复度非常高，结果集很小，distinct 和 group by 在全表扫描阶段都要读完百万行，但因为输出结果只有 1 万行，临时表比较小，耗时反而比 30 万基数低一些，两个 SQL 依旧拉不开差距。

如果你的业务里还有一个唯一键或趋近唯一的高基数字段，比如 SELECT DISTINCT order_no，这时候去重操作面对的结果集接近百万行，临时表排序压力最大。很多人以为 distinct 处理高基数字段天生慢，其实换成 group by 并不会好到哪去。高基数场景真正有效的优化方向是：要么确保 order_no 上有索引，要么考虑这个需求是否真的需要把一百万行唯一值全部返回给应用层。

3. 业务让你算“去重后的数”时，count(distinct)才是最容易踩坑的地方

3.1 count(distinct)被老手嫌弃的几个原因

纯列出唯一值的时候，distinct 和 group by 还只是执行路线之争。一旦业务变成“统计一下有多少个去重用户”，真正的问题就转移到 COUNT(DISTINCT user_id) 上了。

COUNT(DISTINCT) 在 MySQL 5.7 及以前的版本里，处理方式相对粗暴：把去重字段的所有值扔进临时表，在临时表上建唯一索引或做 sort，然后统计行数。字段基数越大，临时表的内存占用越多，一旦超过 max_heap_table_size 或 tmp_table_size 的限制，就会落到磁盘临时表，查询慢得肉眼可见。

这个语法还有一个容易忽略的语义：COUNT(DISTINCT col) 会自动忽略 NULL。如果业务上要求把“未知用户”也算作一种独立用户，直接写 count(distinct) 会少算一条。这类事在报表口径核对时很容易引发争议。

3.2 绕开count(distinct)的两段式写法

当单个 COUNT(DISTINCT ...) 在某个版本的执行计划里不理想，或者你需要在去重之后继续做其他过滤、连接操作时，可以考虑用子查询把 group by 结果包一层：

sql复制SELECT COUNT(1)
FROM (
  SELECT user_id
  FROM t_user_event
  GROUP BY user_id
) t;

这段 SQL 和 COUNT(DISTINCT user_id) 在结果上等价，但在执行计划允许的情况下，优化器可以先完成 group by，再对外层结果做统计。你还可以在子查询里顺手加一些过滤条件，比如只统计最近 7 天有行为的用户，这样外层 count 的压力就更小了。遇到某个引擎的 count(distinct) 优化不好时，这种写法往往能起到奇效。

如果你想把 NULL 也统计进去，最直观的做法是：

sql复制SELECT COUNT(DISTINCT COALESCE(user_id, -1)) FROM t_user_event;

用 COALESCE 把 NULL 替换成一个业务上不会出现的哨兵值，语义就由“忽略 NULL”变成了“NULL 算一种值”，代码评审时也容易解释。

3.3 当去重需求变成“多维去重+分组统计”，group by 几乎成了唯一解

实际业务里，最常见的不是“谁来过”，而是“某一天有多少用户看过”。这种需求要求先按 日期 + user_id 去重，再按日期统计数量。直接使用 COUNT(DISTINCT user_id, event_date) 并不是标准 SQL 的通用写法，不同数据库支持度也不同。更通用的姿势是先 group by 两个维度，再在外层统计：

sql复制SELECT event_date, COUNT(1)
FROM (
  SELECT event_date, user_id
  FROM t_user_event
  GROUP BY event_date, user_id
) t
GROUP BY event_date;

这种需求里，distinct 根本没有办法承担中间的过滤和后续的分组统计，group by 不是“另一个选项”，而是唯一合理选项。很多网上争论把这两种关键字放在绝对对立面，其实在真实报表 SQL 里，distinct 单独出现的频率远低于 group by 配合聚合函数出现的频率。

如果你处理的是数仓里几十亿行的超大表，COUNT(DISTINCT) 在某些分布式引擎里还可能因某个高频值导致数据倾斜，把大量数据压到单节点。这类场景常见解法是换成 HyperLogLog 之类的近似去重算法，比如 Spark 里可以直接 approx_count_distinct。但那是另一个量级的故事，100W 行还远没到需要上近似算法的程度。

4. 需求是“每组取一条明细”时，distinct根本接不住

4.1 想用select * + group by偷懒？MySQL能放你一马但有条件

很多初学者会把“去重”和“取每组的一条明细”搞混。比如想查“每个用户最近一次访问记录”，有人随手就写：

sql复制SELECT *
FROM t_user_event
GROUP BY user_id;

在 MySQL 5.7 之前，如果 sql_mode 没开 ONLY_FULL_GROUP_BY，这句 SQL 确实能执行，查询结果里每个 user_id 只会出一行，其它字段则来自同组内的某一行，具体是哪一行完全不确定。也就是说，你以为自己拿到了“每个用户一条记录”，实际上拿到的是“引擎从每组里随手挑的一条”。

到了 MySQL 5.7 之后，默认开启了 ONLY_FULL_GROUP_BY，这种 SQL 会直接报错，不允许 select 列表里出现既不在 group by 中、也没有被聚合函数包住的字段。到了这一步，distinct 与 group by 的边界反而很清楚：distinct 只能帮你把重复行合并，无法帮你解决“合并时保留哪一行其他字段”的问题。group by 虽然能做分组，但按标准 SQL 语义，它同样不能直接返回组内任意行的非分组字段。

4.2 真正的正统解法：子查询关联、窗口函数和distinct on

要拿“每个用户最近一条事件”，我会优先考虑两种写法。

第一种是子查询找出每组需要的 id，再回表取完整行：

sql复制SELECT t.*
FROM t_user_event t
JOIN (
  SELECT user_id, MAX(id) AS max_id
  FROM t_user_event
  GROUP BY user_id
) m ON m.max_id = t.id;

这种方法可以稳定地取到每组最新一行，逻辑直观，在 MySQL 8.0 之前也通用。但前提是“最新”可以靠 id 或某个唯一列的最大值定义。如果业务要求按某个时间字段排序，而该时间字段可能重复，就需要先在子查询里做去重或增加辅助排序字段，否则关联结果可能多出重复行。

第二种是窗口函数，MySQL 8.0 之后写起来更清晰：

sql复制SELECT user_id, id, event_type, event_time
FROM (
  SELECT t.*,
         ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY event_time DESC, id DESC) AS rn
  FROM t_user_event t
) x
WHERE rn = 1;

这里 PARTITION BY 负责分组，ORDER BY 决定“每组内哪一行排在第一个”，ROW_NUMBER() 给每行编号，最后取每个组里序号为 1 的那行。这种方法把“分组后取一条”的需求写得很明确，也很容易扩展成“每组取前三条”。

如果你在用 PostgreSQL，它还有个语法糖叫 DISTINCT ON，可以直接写成：

sql复制SELECT DISTINCT ON (user_id) *
FROM t_user_event
ORDER BY user_id, event_time DESC;

这个写法非常符合直觉，但要注意 ORDER BY 的起始列必须和 DISTINCT ON 的括号列一致，否则结果不符合预期。这个语法也给 MySQL 用户提供了一种很好的“参照系”：当我们只是想纯粹去重时，用 distinct 就好；当我们需要带着业务字段输出时，只是两个关键字远远不够，需要的是一套新的方案。

4.3 去重字段里的“隐形不同”：大小写、空格和NULL

百万行数据的去重，还有一个经常在测试环境没事、上生产就出问题的点：字段值看起来是一模一样的，但引擎认为它们不同。

比如一个字符串字段使用 utf8mb4_0900_ai_ci 排序规则时，distinct 会把大小写不同、甚至带重音符号的值都视为相同；如果字段定义成 utf8mb4_bin，则 'abc' 和 'ABC' 会被当成两条完全不同的记录。同一个 SQL、同一个数据库版本，只要表字段 collation 不同，去重结果的行数就可能差很多。

再比如 MySQL 里 varchar 字段比较时通常会忽略末尾空格（PAD SPACE 规则），所以 'alice ' 和 'alice' 在 distinct 时会被看成同一个值，但在 LIKE 比较或某些程序语言里，它们是不同的字符串。这类“伪重复”在百万行里很常见，尤其是用户手工填写的昵称、备注字段。真正做数据清洗时，最好先用 TRIM、大小写统一或自定义归一化函数处理后再去重，而不是直接把原始字段丢进 distinct。

NULL 值也值得留意。distinct 会把所有 NULL 当成同一个组输出一行，而 group by 同样会把 NULL 分到一个组里，但如果你在这个组上做计数或关联，NULL 的传播行为可能和业务预期不一致。碰到关键报表，条件允许的话，强烈建议先把 NULL 替换成明确的值再进入去重流程。

5. 我的最终决策链条：先确认需求，再看索引，最后才挑关键字

5.1 一张表看清五种常见场景该用什么

把上面的实测和踩坑汇总一下，几乎可以覆盖大家日常遇到的所有“去重”需求：

这张表也解释了一个现象：为什么很多人实际项目里写 group by 的次数远多于 distinct。因为大多数去重需求的背后，都还点缀着聚合、过滤、分组展示等附加条件，一旦有这些条件，distinct 就很难独当一面。

5.2 几条压箱底的个人经验

如果下次再有人拿“100W 数据该用 distinct 还是 group by”这个问题来问我，我会先反问三个问题：你要的结果里，只有去重键本身，还是需要带上其他统计字段？去重字段上有没有可用的索引？数据库版本是 8.0 还是更老的版本？这三个问题问完，答案基本不需要争。

我自己的习惯是：纯去重列表优先选 distinct，因为代码评审时看到它就能立刻明白“这里不想要重复行”；一旦查询里出现“每组的数量”“每组最大最小值”“每组某条明细”这类需求，立刻换 group by 或窗口函数，不纠结语法之间的性能差异。所有语句写完后，花 30 秒看一眼执行计划，确认有没有 Using temporary、有没有落到磁盘临时表，这比在社区里口嗨哪个关键字更快有用得多。

最后再分享一个土办法：遇到这类“两个写法都行”的 SQL，不要只看网上结论，直接在你自己库里造一张接近线上数据分布的小表，跑一下 EXPLAIN ANALYZE，观察真实耗时。我把百万行测试做下来最大的感受是，distinct 和 group by 的身份差异远没有想象中那么大，真正拖垮 SQL 的通常是没有索引的全表扫描、临时表落盘、携带了过宽的业务字段，以及数据里那批肉眼看不出来但引擎分得很清的“脏值”。这一点想明白了，以后再看到类似的讨论，你就能笑眯眯地翻出执行计划，然后告诉大家：“先看这里再说。”