在数据查询与数据库优化中，GROUP BY 多字段分组究竟承担什么角色？许多初学者容易把它理解为“高级去重”，但其本质是“归并”而非“删除”。GROUP BY 按照指定的字段组合将数据划分为多个小组，每组只返回一行。当执行 SELECT a, b FROM t GROUP BY a, b 时，结果看似实现了去重，实际上是将所有 a、b 值相同的行聚合到一起，再从每组中抽取一行。至于抽取哪一行，MySQL 本身并不能保证确定性。
一个常见的错误场景：当你写出 SELECT code, cdate, ctotal FROM tt GROUP BY code 时，数据库可能直接报错 Expression #2 of SELECT list is not in GROUP BY clause。这通常是因为你使用的是 MySQL 8.0+ 版本，并且默认开启了 ONLY_FULL_GROUP_BY 模式。
这里有三个关键点你必须掌握：
- SELECT 列表中所有非聚合字段必须出现在 GROUP BY 列表中，否则数据库拒绝执行。
- 如果你执意只按
code分组，同时又想输出cdate和ctotal，就必须通过聚合函数来“包装”它们，例如MAX(cdate)、ANY_VALUE(ctotal)。 ANY_VALUE()是 MySQL 提供的“逃生门”，表示你确认“该组内各行的值相同，或者任意取值均可接受”。但它并不保证稳定，在不同版本或执行计划下可能返回不同行。
用 MIN/MAX 等聚合函数控制“留哪一条”
当你想保留每组中某个字段的最小或最大值（例如最早的日期、最小的 ID）时，MIN() 和 MAX() 是最实用且可控的组合方案。
举例说明：从 students 表中，按 name 和 class 进行去重，并且希望保留每组内 id 最小的完整记录。正确写法如下：
SELECT MIN(id) AS id, name, classFROM studentsGROUP BY name, class;
请注意，name 和 class 是分组依据，MIN(id) 是聚合结果。你不能直接写成 SELECT id, name, class GROUP BY name, class，因为 id 既未被聚合，也未被包含在 GROUP BY 子句中，必然导致错误。
这里有两个实用技巧：
- 如果表中包含
created_at字段，想保留每组最新的一条记录，就用MAX(created_at)，再配合子查询或 JOIN 将整行数据取回。 - 聚合函数存在一个天然局限：它会丢弃原始行中的其他字段信息（如
email、phone）。如需保留这些字段，应改用窗口函数或关联子查询。 - 性能方面，如果在
(name, class, id)上创建了复合索引，GROUP BY可以直接利用索引，避免临时表和文件排序，显著提升效率。
MySQL 8.0+ 推荐用 ROW_NUMBER() 实现精确逻辑去重
当需求更为精细时，例如“每个 code 只保留 cdate 最大的一条，并且要带上该行的所有字段”，GROUP BY + MIN/MAX 就显得力不从心——它只能返回聚合后的值，无法原封不动地返回完整行。
此时，窗口函数是最干净的解决方案：
WITH ranked AS ( SELECT *, ROW_NUMBER() OVER (PARTITION BY code ORDER BY cdate DESC, id ASC) AS rn FROM tt)SELECT code, cdate, ctotal, other_colFROM rankedWHERE rn = 1;
ROW_NUMBER() 确保每组内严格按指定顺序编号。PARTITION BY code 定义分组规则，ORDER BY cdate DESC, id ASC 决定“谁排第一”（先按日期降序，日期相同时再按 ID 升序，避免歧义）。
使用时的注意事项：
- 窗口函数必须通过 CTE 或子查询封装，不能直接出现在 WHERE 子句中。
- ORDER BY 中的字段必须能决定唯一顺序（例如加上
id），否则相同cdate下的行顺序不可预测。 - 如果只需要去重后的部分字段，可以精简 SELECT 列表，但不要在
SELECT *中随意删列，以免遗漏业务关键字段。
别在 GROUP BY 里混入高粒度字段
一个极易踩坑的地方：在 GROUP BY 中加入近似唯一的字段（如 order_id、created_at、uuid），导致分组粒度极细，结果看上去根本没有去重效果。
例如，你写 SELECT user_id, COUNT(DISTINCT product_id) FROM orders GROUP BY user_id, order_id。由于每个订单的 order_id 都不同，实际上每一行自成一组，COUNT(DISTINCT product_id) 的结果永远是 1。
预防方法：
- 检查 GROUP BY 列表是否只包含真正代表“业务维度”的字段，比如
user_id、date、region。 - 运行一句
SELECT COUNT(*)和COUNT(DISTINCT target_col)对比，如果两个数字非常接近，说明分组粒度可能过细。 - 如果既要保留明细，又要粗粒度统计，可以先在子查询中按目标维度聚合，再在外层对结果进行计算。
归根结底，SQL 中最难的从来不是语法本身，而是想清楚“我到底要用什么逻辑来定义重复”。字段组合的语义理不清，再漂亮的 SQL 也救不回来。
