面试官：MySQL中的 distinct 和 group by 哪个效率更高？

一、开篇一道高频面试题背后的问题在 MySQL 相关的面试中有一道题经常被面试官问到distinct 和 group by 都能去重它们哪个效率更高很多候选人听到这个问题后会下意识地回答「distinct 更快因为它的语义更简单」也有一些人会回答「group by 更快因为它功能更强」。实际上这道题并没有一个脱离场景的唯一答案。要回答好这道题不能只停留在「谁比谁快」的结论上而应该从 SQL 语义、执行计划、索引使用、临时表、排序和优化器行为几个维度展开。本文将以 MySQL 8.0 为主要版本结合 InnoDB 存储引擎从原理到实验系统地把 distinct 与 group by 的去重机制讲清楚并给出不同场景下的选择建议。整篇文章将覆盖以下几个方面distinct 与 group by 的基础语法和语义差异两种写法在优化器中的执行计划差异单列去重与多列去重的内部处理方式count(distinct) 的特殊性和性能问题索引对去重效率的影响临时表、文件排序和内存限制的作用性能实测数据对比group by 相比 distinct 的额外能力不同业务场景下的选择策略和优化建议围绕这道题常见的面试追问在正式开始之前需要先说明一点本文讨论的是「用 group by 实现去重」与「直接使用 distinct 去重」之间的效率对比默认查询最终返回的都是去重后的结果集。理解了这一点后面的分析和实验才有统一的比较基准。二、基础回顾distinct 与 group by 的用法2.1 distinct 的语法与语义distinct 是 SELECT 语句中的一个关键字用来去除查询结果中的重复行。它的位置通常紧跟在 SELECT 之后作用于 SELECT 列表中的全部列。也就是说distinct 去重的对象不是某一列而是整行记录的组合。例如有一张用户表 user里面记录了用户的城市和职业CREATE TABLE user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, city VARCHAR(50) NOT NULL, job VARCHAR(50) NOT NULL, KEY idx_city (city) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;如果只想查询所有出现过的城市可以使用SELECT DISTINCT city FROM user;如果查询的是 city 和 job 两列去重的就是「城市和职业」这个二元组合SELECT DISTINCT city, job FROM user;注意distinct 关键字的位置不能随意放在列后面它是一种作用于整行结果的关键字。比如下面这种写法是不符合语法的SELECT city, DISTINCT job FROM user; -- 错误写法2.2 group by 的语法与语义group by 是 SQL 中的分组关键字它会按照指定列的值把结果集分成若干组每组最终输出一行。由于每个分组的列值相同因此从结果上看group by 指定的列天然具有去重效果。同样查询所有出现过的城市用 group by 可以写成SELECT city FROM user GROUP BY city;查询城市和职业组合时SELECT city, job FROM user GROUP BY city, job;从去重效果来看上面两条 group by 语句分别等价于对应的 distinct 语句。但二者的语义并不完全相同group by 除了去重以外还允许对每个分组进行聚合计算而 distinct 本身不具备聚合能力。三、从执行计划看本质差异要判断 distinct 和 group by 谁更高效首先要看优化器如何解析和执行这两类语句。执行计划是分析 SQL 性能最直接的入口使用 EXPLAIN 可以查看优化器选择的访问路径。3.1 distinct 的执行计划先建立一个测试表并写入一定量的数据DROP TABLE IF EXISTS t_distinct_test; CREATE TABLE t_distinct_test ( id INT PRIMARY KEY AUTO_INCREMENT, category INT NOT NULL, name VARCHAR(100) NOT NULL, create_time DATETIME NOT NULL, KEY idx_category (category) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;查看单列 distinct 的执行计划EXPLAIN SELECT DISTINCT category FROM t_distinct_test;如果 category 字段上存在索引 idx_category优化器通常会优先选择该索引进行扫描并利用Loose Index Scan或索引顺序扫描来避免创建临时表。此时 Extra 列中可能会出现Using index for group-by之类的提示。需要说明的是虽然提示中有 group-by 字样但它表示的是优化器采用了松散索引扫描这种针对分组和去重场景的优化策略distinct 和 group by 都可能受益。如果去重字段没有可用索引执行计划往往会显示出Using temporary这意味着 MySQL 需要借助临时表来存储已经出现过的值并在插入时判断是否重复。3.2 group by 的执行计划查看对同一列进行分组的执行计划EXPLAIN SELECT category FROM t_distinct_test GROUP BY category;当 category 列有索引时group by 同样可以走索引。与 distinct 类似优化器也可能采用松散索引扫描。对于只包含分组列、没有聚合函数的简单分组查询MySQL 的优化器在很多情况下会把 group by 和 distinct 的执行路径优化得非常接近甚至生成等价的执行计划。也就是说在最简单的「单列去重且该列有索引」场景下distinct 和 group by 的性能几乎没有明显差异二者都可能通过索引高效完成去重。3.3 关键区别不一定在执行计划而在功能定位需要纠正一个常见误解很多人认为 distinct 一定比 group by 快理由是 distinct 只需要判断重复而 group by 还要分组排序。实际上MySQL 的 group by 并不一定要求排序只有显式使用 ORDER BY 或者某些特定执行路径才会产生排序开销。而 distinct 在必要时同样会使用临时表。因此单纯从「关键字语义」判断效率是不准确的真正决定性能的是去重列是否有索引、数据量大小、去重后的基数高低、内存是否充足、是否需要额外排序这些条件。四、单列去重的内部处理4.1 有索引时的去重策略假如查询语句是SELECT DISTINCT category FROM t_distinct_test;并且 category 列上建立了普通索引那么 InnoDB 的二级索引叶子节点中保存的是「索引列值加主键值」并且索引本身按照 category 的顺序排列。由于相同 category 的记录在索引中是连续存放的扫描索引时只需要读取第一个值然后跳过后续相同的值即可。对于 group by 的等价写法SELECT category FROM t_distinct_test GROUP BY category;MySQL 同样可以利用索引的有序性进行分组。Optimizer 在扫描索引时每遇到一个新的 category 值就输出一行这被称为松散索引扫描。这种扫描方式不需要把全部记录加载到临时表中内存占用小执行效率高。在有合适索引的情况下简单 distinct 和简单 group by 的去重成本都是 O(n) 级别的扫描成本差别很小。真正拉开差距的往往是那些更复杂的查询形态。4.2 无索引时的临时表处理当去重列没有索引时MySQL 无法借助有序性去重只能建立一个临时表。临时表可以是内存表也可以是磁盘表。执行过程大致如下扫描源表记录对每一条记录判断其去重键是否已经存在于临时表如果不存在则插入临时表并输出或暂存该行如果存在则跳过当数据量较大、临时表超过 tmp_table_size 或 max_heap_table_size 限制时MySQL 会把内存临时表转为磁盘临时表使用 MyISAM 或 TempTable 存储引擎性能会明显下降。在这种情况下distinct 和 group by 都可能使用临时表二者的底层开销接近。相对而言group by 在支持聚合时还可以做更多优化而 distinct 的能力边界则停留在去重。五、多列去重的差异5.1 distinct 作用于整行distinct 的语义是对 SELECT 列表中的所有列组成的行进行去重。例如SELECT DISTINCT city, job FROM user;这条语句会返回 city 和 job 都不重复的组合。如果 user 表有 100 万行但 city 和 job 的组合只有 1 万种那么最终返回 1 万行。在执行计划上如果 city 和 job 上存在联合索引 idx_city_jobMySQL 可能通过该索引完成去重。但如果只对 city 建了索引、job 没有索引那么仅靠 city 索引无法保证 city 和 job 组合在索引中是连续有序的优化器的选择就会更复杂可能需要回表后再进行去重或使用临时表。5.2 group by 同样作用于分组列组合使用 group by 的等价写法是SELECT city, job FROM user GROUP BY city, job;这里 city 和 job 是分组列结果同样是去重后的组合。与 distinct 相比二者的语义在「只查分组列」时几乎一致。但如果查询中增加了聚合函数语义就开始分化SELECT city, job, COUNT(*) AS cnt FROM user GROUP BY city, job;这种查询 distinct 无法直接替代。即便使用 distinct 配合窗口函数或其他手段模拟写法也复杂得多。这正是 group by 相比 distinct 最本质的优势之一。5.3 多列去重中容易出现的一个误区有些开发者会写成SELECT DISTINCT city, job FROM user WHERE city 北京;并认为 where 条件中的 city 已经固定distinct 只需要对 job 去重。这个理解在结果层面是对的但优化器是否能据此降低去重成本取决于索引情况。如果存在 (city, job) 联合索引利用索引最左前缀匹配city 固定后 job 依然有序去重效率会很高如果只有单列 city 索引job 部分仍可能需要额外去重。六、count(distinct) 的特殊问题在涉及 distinct 的面试题中count(distinct) 是一个绕不开的进阶点。它的性能和普通 distinct 查询有明显差异也经常被用来考察候选人对执行计划的理解深度。6.1 count(distinct col) 能走普通索引吗先看一个常见查询SELECT COUNT(DISTINCT category) FROM t_distinct_test;这里要统计 category 的去重个数。与 SELECT DISTINCT category 不同count(distinct) 需要得到去重后的记录数量而不是去重后的明细行。当 category 上有索引时show 执行计划或用 EXPLAIN ANALYZE 观察MySQL 是否能利用索引完成 count(distinct)在不同版本中表现不同。在 MySQL 8.0 中对于 COUNT(DISTINCT col) 这类聚合优化器通常可以扫描索引但仍然可能需要在扫描过程中进行去重统计。如果 category 没有索引或者需要对多列进行 count(distinct)执行成本会显著上升因为需要维护一个较大的去重集合且无法简单利用索引顺序。6.2 count(distinct a, b) 的代价考察下面这种查询SELECT COUNT(DISTINCT city, job) FROM user;这种写法需要对 city 和 job 的组合进行去重后再计数。即便 city 上有索引、job 上也有索引如果不存在 (city, job) 联合索引MySQL 也很难直接利用单个索引完成组合去重。底层实现上MySQL 可能在扫描结果的基础上维护一个去重结构。去重集合越大内存占用越高一旦超过最大限制就会落盘性能急剧下降。这也是为什么在数据仓库和大数据量报表中count(distinct) 经常是性能瓶颈之一。6.3 count(distinct) 的一些优化思路如果业务确实需要统计去重个数可以考虑以下优化方案为需要去重的列建立合适的联合索引使优化器能够有效利用索引顺序把 count(distinct col) 改写为对「列为主键或唯一键的子查询」进行计数使用 group by 加 count(*) 的写法再对分组结果进行计数必要时借助子查询或派生表在大数据量场景下先在应用层或 ETL 阶段做近似去重如使用 HyperLogLog 思路检查 innodb_buffer_pool_size 和临时表相关参数降低落盘概率下面是一种常见的改写方式使用派生表把去重和计数拆开让执行计划更清晰-- 原始写法 SELECT COUNT(DISTINCT category) FROM t_distinct_test; -- 改写为先去重再计数 SELECT COUNT(*) FROM ( SELECT category FROM t_distinct_test GROUP BY category ) AS dedup;这种改写并不一定总是更快但至少可以让去重过程和计数过程分离便于进一步针对索引和执行计划进行优化。七、索引如何影响效率7.1 覆盖索引与回表在讨论 distinct 和 group by 的效率时索引是一个核心变量。以查询单个去重列为例SELECT DISTINCT category FROM t_distinct_test;如果 category 上有普通索引并且查询只需要 category 列那么该索引就是覆盖索引。扫描二级索引时可以直接获得 category 值不需要回表查询聚簇索引IO 成本较低。但如果查询还包含其他列例如SELECT DISTINCT category, name FROM t_distinct_test;而索引只有 idx_category(category)那么扫描 category 索引找到候选记录后还需要根据主键回表读取 name 列再进行整行去重。此时扫描成本虽然可能降低但回表成本仍然存在是否划算取决于过滤后的数据量。7.2 索引顺序与去重方向如果去重列有索引且查询不需要额外排序distinct 和 group by 都能按索引顺序读取。但如果查询要求结果按另一列排序就需要额外排序SELECT DISTINCT category FROM t_distinct_test ORDER BY category;当 ORDER BY 的列与去重列一致且索引顺序匹配时排序可以省去。反之如果排序字段不同优化器可能先完成去重再做 filesort。group by 也有类似问题。group by 默认并不保证结果有序虽然旧版本在某些存储引擎下会隐式排序但 MySQL 8.0 已经移除对隐式排序的依赖。因此不要假设 group by 的结果天然按分组列排序。7.3 联合索引的覆盖能力对于多列去重联合索引的设计非常关键。比如频繁执行SELECT DISTINCT city, job FROM user;此时建立联合索引 idx_city_job(city, job) 对去重最有帮助。扫描该索引时city、job 组合天然有序相同组合连续出现去重成本最低。需要注意联合索引的顺序要和查询中的列顺序、过滤条件相匹配。如果更多查询是「先按 job 过滤再按 city 去重」那么可能建立 (job, city) 联合索引会更合适。联合索引设计要结合真实业务查询而不是机械套用某一种写法。例如如果查询还经常包含 create_time 条件也可以考虑在高频过滤列的基础上组合去重列但索引列越多写入和维护成本也会越高需要在查询收益和写入成本之间做平衡。八、临时表、文件排序与内存限制的作用当 distinct 或 group by 无法借助索引直接完成去重或分组时MySQL 通常会退回到临时表。临时表的工作方式以及和它密切相关的文件排序、内存参数往往是不同 SQL 写法之间出现性能差距的关键来源。8.1 临时表会在哪些情况下被使用以下几种情况很容易触发Using temporary去重或分组列没有可用索引。多列去重的组合与现有索引顺序不匹配。去重或分组前还需要进行函数计算、类型转换、隐式转换。SQL 中同时包含不同字段的 ORDER BY优化器无法直接复用同一个索引顺序。执行计划中出现Using temporary时说明 MySQL 需要借助一个额外的中间结构来保存中间结果。这个中间结构可能只存在于内存中也可能落到磁盘上两者的开销差距非常大。8.2 内存临时表与磁盘临时表的区别MySQL 会优先创建内存临时表。内存临时表的大小受到tmp_table_size和max_heap_table_size两个参数的共同限制取两者中的较小值作为内存临时表的上限。当中间结果超过这个上限后MySQL 会把临时表转成磁盘临时表。磁盘临时表可能使用 TempTable 引擎并落到 InnoDB 的磁盘表空间也可能在特定场景下使用 MyISAM。无论哪种实现磁盘 IO 的开销都会让处理速度明显下降。所以同样是去重在小数据量下 distinct 和 group by 可能都很快但数据量一旦超过内存阈值导致临时表落盘整体耗时可能成倍上升。这也是很多开发者在线上写出慢 SQL测试环境却表现正常的原因之一。8.3 filesort 对去重查询的影响如果查询结果需要按照非索引顺序排序MySQL 就会使用 filesort。filesort 并不是一定写文件它首先在sort_buffer_size指定的排序缓冲区中排序只有当数据量超过缓冲区大小时才会使用外部归并排序并写到磁盘。以一个常见场景为例SELECT DISTINCT category FROM t_distinct_test ORDER BY name;这里去重列是 category排序列是 name。如果只有 category 索引优化器可以先利用索引完成去重然后对去重结果执行 filesort。去重后如果结果仍然很大filesort 的成本可能比去重本身更高。group by 也有相同问题。不要假设分组列和排序列一致就一定没有排序也不要假设 group by 一定有排序最终要看优化器选择的执行路径和表上的索引设置。8.4 调优时应该关注哪些参数如果确认 SQL 出现了临时表或文件排序问题可以从这些参数和设计维度入手tmp_table_size控制内存临时表上限可结合业务数据量适当调大但不能无限调大。max_heap_table_size与控制内存表大小相关的参数和 tmp_table_size 共同生效。sort_buffer_size控制 filesort 缓冲区大小影响排序是否容易落盘。innodb_buffer_pool_size保证热点索引和数据尽量留在缓冲池中减少磁盘读。把去重/分组列和排序列纳入索引设计从根源上减少临时表和 filesort。九、性能实测不同场景下的数据对比前面更多是从执行计划角度分析下面用一个简单的测试场景把不同条件下 distinct 和 group by 的表现做一个直观对比。这里的数值是示例环境中的一组测试结果重点看趋势不做绝对性能承诺。9.1 测试数据准备继续使用前面建立的t_distinct_test表向表中写入 100 万行测试数据category列基数约为 1 万值分布不均匀。name列使用随机字符串重复度较低。create_time覆盖最近一年的时间范围。分别测试无索引、单列 category 索引、联合索引条件下的耗时。每次查询执行多次后取平均值避免单次波动影响结论。9.2 单列去重场景对比语句SELECT DISTINCT category FROM t_distinct_test; SELECT category FROM t_distinct_test GROUP BY category;示例数据如下场景索引情况distinct 平均耗时group by 平均耗时结论单列去重 category无索引约 890 ms约 900 ms二者接近临时表开销明显单列去重 categorycategory 上有索引约 45 ms约 48 ms差异很小都走索引去重可以看到在有索引时简单 distinct 和简单 group by 的耗时几乎可以忽略差异在无索引时两者都会受到临时表影响耗时明显上升。9.3 多列去重场景对比语句SELECT DISTINCT city, job FROM user; SELECT city, job FROM user GROUP BY city, job;示例数据如下场景索引情况distinct 平均耗时group by 平均耗时结论多列去重 city, job只有 city 单列索引约 1350 ms约 1380 ms无法直接利用索引组合成本高多列去重 city, job(city, job) 联合索引约 65 ms约 62 ms联合索引显著降低去重成本这说明多列去重时联合索引的收益要远大于在 distinct 和 group by 两种写法之间反复纠结。9.4 从实测结果中读出的结论在简单的单列去重、有合适索引时distinct 和 group by 性能差异很小。在无索引或多列去重无法利用联合索引时二者的性能都会明显下降且差距不大。真正决定性能的是索引设计、数据量、去重基数、临时表是否落盘和排序需求。与其纠结用哪个关键字不如先检查去重列有没有合适的索引。十、group by 相比 distinct 的额外能力理解了执行计划之后就可以回答面试中常见的另一个问题既然 distinct 和 group by 都能去重为什么还要用 group by这是因为 group by 的功能边界远不止去重。10.1 聚合计算group by 可以和聚合函数直接配合统计每个分组内的数量、总和、平均值、最大值和最小值SELECT city, COUNT(*) AS user_count FROM user GROUP BY city;而 distinct 只能返回不重复的行本身不具备聚合能力。要想用 distinct 同时得到计数往往需要借助子查询、窗口函数或额外扫描写法复杂得多。10.2 HAVING 分组后过滤group by 之后可以使用 HAVING 对分组结果继续过滤SELECT city, COUNT(*) AS user_count FROM user GROUP BY city HAVING COUNT(*) 100;这种“分组后再筛选组”的能力是 distinct 不具备的。10.3 多级汇总与 WITH ROLLUPgroup by 可以配合WITH ROLLUP生成小计行和总计行SELECT city, job, COUNT(*) AS cnt FROM user GROUP BY city, job WITH ROLLUP;这种用于报表和统计的写法distinct 也无法直接实现。10.4 ONLY_FULL_GROUP_BY 下的语义差异MySQL 8.0 默认开启ONLY_FULL_GROUP_BY。启用后SELECT 列表中的非聚合列必须出现在 group by 子句中-- ONLY_FULL_GROUP_BY 下可能报错 SELECT city, job FROM user GROUP BY city;这说明 group by 承载的是一整套分组聚合语义而 distinct 只承载“结果去重”这一件事。二者定位不同不能简单互替。十一、不同业务场景下的选择策略与优化建议综合前面的分析可以把实际工作场景归为几类分别给出选择建议。11.1 只需要去重不需要聚合如果需求只是取出去重后的列值或行组合推荐优先使用 distinct。它的语义更直接代码可读性更好。在去重列有索引时性能和 group by 没有本质区别。11.2 去重后还要聚合、分组或过滤如果去重只是第一步后续还要 count、sum、avg或者需要按分组条件过滤应直接使用 group by。这样可以一次完成分组和聚合避免绕行派生表。11.3 多列去重优先设计联合索引对于列组合去重优先把去重列按照业务查询顺序建成联合索引。联合索引能让去重从临时表方案变成索引扫描方案收益通常远超调整 SQL 关键字。11.4 面向接口的列表去重要区分层级有些“去重”问题本质是业务模型问题例如分页后出现重复数据、关联查询放大结果。此时不应该通过无脑加 distinct 掩盖问题而应检查连接条件、数据粒度或主键生成逻辑。11.5 超大表和报表场景在数据量很大的报表场景尽量避开直接 count(distinct)优先用 group by 派生表分别完成去重和计数。对允许误差的统计可以考虑 HyperLogLog 等近似去重方案。把高频统计下推到数仓、ES、ClickHouse 等擅长聚合的组件中。检查临时表落盘情况必要时在 ETL 阶段预先聚合。十二、高频面试追问与回答要点回到这道面试题本身。面试官真正想考察的不是让候选人背出一个“标准答案”而是看候选人能否根据执行计划和场景差异讲清原因。12.1 distinct 一定比 group by 快吗不是。在简单单列去重且去重列有索引时两者性能接近在无索引或多列去重时两者的临时表成本接近。性能主要取决于索引、数据量、去重基数和排序需求。12.2 count(distinct) 为什么经常成为慢查询因为 count(distinct) 需要维护去重结果才能统计数量去重集合越大越容易占用大量内存超过限制后就会落盘。多列 count(distinct) 更难直接利用单个索引。可以改写为 group by 派生表再计数或考虑近似去重方案。12.3 group by 一定需要排序吗不一定。MySQL 8.0 中 group by 默认不会隐式保证排序结果只有显式 ORDER BY 或某些执行路径才会产生排序成本。如果结果需要稳定顺序应显式写 ORDER BY。12.4 松散索引扫描是什么松散索引扫描是 MySQL 利用索引有序性进行去重或分组的一种方式。扫描索引时每遇到一个新的去重键就输出一行跳过后续相同值相比把所有数据加载到临时表能显著节省内存和 IO。12.5 多列去重时怎么设计索引优先为去重列建立联合索引索引列顺序要和查询条件、分组顺序匹配。例如高频查询是 city 加 job 去重就考虑 (city, job) 联合索引。同时应结合实际查询中的过滤列、排序需求来综合设计。12.6 为什么 group by 能聚合而 distinct 不能因为 distinct 是面向整行结果集去重的关键字功能定位在“去掉重复行”group by 是分组子句核心作用是建立分组上下文再配合聚合函数对每一组进行计算二者功能边界不同。十三、总结与回答模板回到文章开头的高频面试题。比较稳妥的回答方式是distinct 和 group by 在“简单去重”这一目标上可以等价实现而效率高低主要不取决于关键字本身而取决于去重列是否有索引、是否需要联合索引、去重后的基数多大、临时表和排序是否落盘。只有去重需求且语义清晰时优先用 distinct去重之后还要聚合、分组过滤或汇总统计时用 group by。优化时先看执行计划和索引设计再决定 SQL 写法。整体判断逻辑可以概括为三步第一步看需求是只去重还是要聚合第二步看执行计划是否存在全表扫描、临时表、filesort第三步看索引能不能用覆盖索引或联合索引把去重成本降到最低。大多数场景下distinct 和 group by 的性能差距远没有“索引不合理、临时表落盘、排序字段没有索引”带来的影响大。掌握这个分析框架远比记住“谁更快”的结论更有价值。