MySQL中的distinct与group by如何使用
先说大致的结论：在语义相同，有索引的情况下：groupby和distinct都能使用索引，效率相同。在语义相同，无索引的情况下：distinct效率高于groupby。原因是distinct和groupby都会进行分组操作，但groupby可能会进行排序，触发filesort，导致sql执行效率低下。基于这个结论，你可能会问：为什么在语义相同，有索引的情况下，groupby和distinct效率相同？在什么情况下，groupby会进行排序操作？带着这两个问题找答案。接下来，我们先来看一下distinct和
先说大致的结论 ：
在语义相同，有索引的情况下：
group by和distinct都能使用索引，效率相同。在语义相同，无索引的情况下：
distinct效率高于group by。原因是 distinct 和group by都会进行分组操作，但group by可能会进行排序，触发 filesort，导致 sql 执行效率低下。
基于这个结论，你可能会问：
为什么在语义相同，有索引的情况下，
group by和distinct效率相同？在什么情况下，
group by会进行排序操作？
带着这两个问题找答案。接下来，我们先来看一下 distinct 和group by的基础使用。
distinct的使用
distinct用法
SELECT DISTINCT columns FROM table_name WHERE where_conditions;
例如：
mysql> select distinct age from student; +------+ | age | +------+ | 10 | | 12 | | 11 | | NULL | +------+ 4 rows in set (0.01 sec)
DISTINCT 关键词用于返回唯一不同的值。放在查询语句中的第一个字段前使用，且作用于主句所有列。
如果列具有 NULL 值，并且对该列使用DISTINCT子句，MySQL 将保留一个 NULL 值，并删除其它的 NULL 值，因为DISTINCT子句将所有 NULL 值视为相同的值。
distinct 多列去重
distinct 多列的去重，则是根据指定的去重的列信息来进行，即只有所有指定的列信息都相同，才会被认为是重复的信息。
SELECT DISTINCT column1,column2 FROM table_name WHERE where_conditions; mysql> select distinct sex,age from student; +--------+------+ | sex | age | +--------+------+ | male | 10 | | female | 12 | | male | 11 | | male | NULL | | female | 11 | +--------+------+ 5 rows in set (0.02 sec)
group by的使用
对于基础去重来说，group by 的使用和 distinct 类似。
单列去重
语法：
SELECT columns FROM table_name WHERE where_conditions GROUP BY columns;
执行：
mysql> select age from student group by age; +------+ | age | +------+ | 10 | | 12 | | 11 | | NULL | +------+ 4 rows in set (0.02 sec)
多列去重
语法：
SELECT columns FROM table_name WHERE where_conditions GROUP BY columns;
执行：
mysql> select sex,age from student group by sex,age; +--------+------+ | sex | age | +--------+------+ | male | 10 | | female | 12 | | male | 11 | | male | NULL | | female | 11 | +--------+------+ 5 rows in set (0.03 sec)
区别示例
两者的语法区别在于，group by可以进行单列去重，group by的原理是先对结果进行分组排序，然后返回每组中的第一条数据。且是根据group by的后接字段进行去重的。
例如：
mysql> select sex,age from student group by sex; +--------+-----+ | sex | age | +--------+-----+ | male | 10 | | female | 12 | +--------+-----+ 2 rows in set (0.03 sec)
distinct和group by原理
在大多数例子中，DISTINCT可以被看作是特殊的GROUP BY，它们的实现都基于分组操作，且都可以通过松散索引扫描、紧凑索引扫描(关于索引扫描的内容会在其他文章中详细介绍，就不在此细致介绍了)来实现。
DISTINCT和GROUP BY都是可以使用索引进行扫描搜索的。例如以下两条 sql（只单单看表格最后 extra 的内容），我们对这两条 sql 进行分析，可以看到，在 extra 中，这两条 sql 都使用了紧凑索引扫描Using index for group-by。
所以，在一般情况下，对于相同语义的DISTINCT和GROUP BY语句，我们可以对其使用相同的索引优化手段来进行优化。
mysql> explain select int1_index from test_distinct_groupby group by int1_index; +----+-------------+-----------------------+------------+-------+---------------+---------+---------+------+------+----------+--------------------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-----------------------+------------+-------+---------------+---------+---------+------+------+----------+--------------------------+ | 1 | SIMPLE | test_distinct_groupby | NULL | range | index_1 | index_1 | 5 | NULL | 955 | 100.00 | Using index for group-by | +----+-------------+-----------------------+------------+-------+---------------+---------+---------+------+------+----------+--------------------------+ 1 row in set (0.05 sec) mysql> explain select distinct int1_index from test_distinct_groupby; +----+-------------+-----------------------+------------+-------+---------------+---------+---------+------+------+----------+--------------------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-----------------------+------------+-------+---------------+---------+---------+------+------+----------+--------------------------+ | 1 | SIMPLE | test_distinct_groupby | NULL | range | index_1 | index_1 | 5 | NULL | 955 | 100.00 | Using index for group-by | +----+-------------+-----------------------+------------+-------+---------------+---------+---------+------+------+----------+--------------------------+ 1 row in set (0.05 sec)
但对于GROUP BY来说，在 MYSQL8.0 之前，GROUP Y默认会依据字段进行隐式排序。
可以看到，下面这条 sql 语句在使用了临时表的同时，还进行了 filesort。
mysql> explain select int6_bigger_random from test_distinct_groupby GROUP BY int6_bigger_random; +----+-------------+-----------------------+------------+------+---------------+------+---------+------+-------+----------+---------------------------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-----------------------+------------+------+---------------+------+---------+------+-------+----------+---------------------------------+ | 1 | SIMPLE | test_distinct_groupby | NULL | ALL | NULL | NULL | NULL | NULL | 97402 | 100.00 | Using temporary; Using filesort | +----+-------------+-----------------------+------------+------+---------------+------+---------+------+-------+----------+---------------------------------+ 1 row in set (0.04 sec)
隐式排序
对于隐式排序，我们可以参考 MySQL 官方的解释：
https://dev.mysql.com/doc/refman/5.7/en/order-by-optimization.html
GROUP BY implicitly sorts by default (that is, in the absence of ASC or DESC designators for GROUP BY columns). However, relying on implicit GROUP BY sorting (that is, sorting in the absence of ASC or DESC designators) or explicit sorting for GROUP BY (that is, by using explicit ASC or DESC designators for GROUP BY columns) is deprecated. To produce a given sort order, provide an ORDER BY clause.
大致解释一下：
GROUP BY 默认隐式排序（指在 GROUP BY 列没有 ASC 或 DESC 指示符的情况下也会进行排序）。然而，GROUP BY 进行显式或隐式排序已经过时（deprecated）了，要生成给定的排序顺序，请提供 ORDER BY 子句。
所以，在 MySQL8.0 之前,GROUP BY会默认根据作用字段（GROUP BY的后接字段）对结果进行排序。在能利用索引的情况下，GROUP BY不需要额外进行排序操作；但当无法利用索引排序时，MySQL 优化器就不得不选择通过使用临时表然后再排序的方式来实现GROUP BY了。
且当结果集的大小超出系统设置临时表大小时，MySQL 会将临时表数据 copy 到磁盘上面再进行操作，语句的执行效率会变得极低。这也是 MySQL 选择将此操作（隐式排序）弃用的原因。
基于上述原因，Mysql 在 8.0 时，对此进行了优化更新：
https://dev.mysql.com/doc/refman/8.0/en/order-by-optimization.html
Previously (MySQL 5.7 and lower), GROUP BY sorted implicitly under certain conditions. In MySQL 8.0, that no longer occurs, so specifying ORDER BY NULL at the end to suppress implicit sorting (as was done previously) is no longer necessary. However, query results may differ from previous MySQL versions. To produce a given sort order, provide an ORDER BY clause.
大致解释一下：
从前（MySQL5.7 版本之前），Group by 会根据确定的条件进行隐式排序。在 MySQL 8.0 中，已经移除了这个功能，所以不再需要通过添加order by null 来禁止隐式排序了，但是，查询结果可能与以前的 MySQL 版本不同。要生成给定顺序的结果，请按通过ORDER BY指定需要进行排序的字段。
因此，我们的结论也出来了：
在语义相同，有索引的情况下：
group by和distinct都能使用索引，效率相同。因为group by和distinct近乎等价，distinct 可以被看做是特殊的group by。在语义相同，无索引的情况下：
distinct效率高于group by。原因是distinct和group by都会进行分组操作，但group by在 MySQL8.0 之前会进行隐式排序，导致触发 filesort，sql 执行效率低下。但从 MySQL8.0 开始，MySQL 就删除了隐式排序，所以，此时在语义相同，无索引的情况下，group by和distinct的执行效率也是近乎等价的。
相比于distinct来说，group by的语义明确。且由于 distinct 关键字会对所有字段生效，在进行复合业务处理时，group by的使用灵活性更高，group by能根据分组情况，对数据进行更为复杂的处理，例如通过having对数据进行过滤，或通过聚合函数对数据进行运算。
详解Navicat导入数据库的标准步骤，涵盖SQL脚本执行与CSV数据导入两种核心场景。针对导入过程中常见的字符集乱码、主键冲突及外键约束错误，提供具体的设置方法与修复建议，确保数据迁移准确无误。
深入理解SQL PRIMARY KEY与UNIQUE约束的区别。文章从行标识与重复限制的目标出发，详解主键的非空特性、外键引用角色以及多数据库对NULL值的处理差异。结合users表实战示例，指导开发者如何根据字段稳定性与业务语义合理选择约束类型，避免设计误区。
刚开始设计关系型数据库？了解PRIMARY KEY、FOREIGN KEY、UNIQUE、NOT NULL、CHECK、DEFAULT等约束的作用、语法和排错方法。本文以PostgreSQL语法为主，结合用户订单场景，清晰展示如何防止脏数据并处理常见约束冲突。
深入解析SQL游标导致的死锁与资源未释放问题。通过PostgreSQL与MySQL语法对比，展示如何识别长事务持锁、分析锁等待链，并提供短事务提交、异常清理及批量处理的最佳实践，确保数据库连接与锁资源及时释放。
后端开发者在维护数据库时，常需对现有表添加主键、唯一或外键约束。若直接执行ADD CONSTRAINT，往往因存量数据不合规导致报错。本文详解操作前的数据清洗步骤、标准SQL语法及MySQL等特殊写法，帮助你在生产环境安全完成结构变更。
针对 SQL 初学者的分组统计实战指南。深入解析 GROUP BY 分组机制、WHERE 与 HAVING 的执行时机差异，以及 COUNT 函数对 NULL 值的处理逻辑。通过具体代码示例演示如何正确筛选聚合结果，并排查因 JOIN 连接导致的统计数据异常，提升报表准确性。
本文详细对比SQL Server和MySQL中游标的基本用法。从DECLARE声明到FETCH遍历，再到CLOSE关闭与DEALLOCATE/Handler清理，解析两者在语法结构、变量接收及异常处理上的核心差异。通过标准代码示例展示如何安全使用游标，避免资源泄漏，适用于需要进行数据库存储过程开发或跨平台迁移的开发者。
深入解析SQL中INNER JOIN与LEFT JOIN的核心区别。通过users和orders表实例，展示匹配行保留与NULL补位机制，重点讲解ON与WHERE子句中放置右表过滤条件的不同后果，提供防止LEFT JOIN退化的实战技巧及行数异常排查步骤。
深入理解 SQL CHECK 约束在 PostgreSQL、MySQL 等数据库中的实现差异。文章通过订单业务场景，讲解如何定义单列范围与多列逻辑约束，分析 NULL 值对布尔条件的影响，并提供修改已有表结构时的安全操作建议，帮助开发者构建更健壮的数据完整性防线。
后端开发中，如何正确使用 SQL 外键约束来维护订单与明细表的关系？本文通过 PostgreSQL 示例，深入讲解外键的创建语法、插入顺序要求，以及 ON DELETE CASCADE、RESTRICT、SET NULL 等策略的实际影响与风险控制，助你构建健壮的数据库结构。
火山引擎是字节跳动旗下企业级云与AI服务平台。聚焦大模型核心能力，依托字节自研豆包多模态大模型，凭借火山方舟一站式平台，提供模型精调、推理部署、智能应用搭建等全链路服务，结合高性能AI算力，助力各行业快速落地大模型数字化与智能化应用。
