mysql中group by默认排序是因其实现机制：无索引时需全表扫描、写临时表并外部排序（using filesort）后分组，i/o与cpu开销大；消除排序和临时表的关键是使用满足最左前缀、顺序一致、字段全覆盖的覆盖索引，且可用order by null显式禁用隐式排序。
GROUP BY 为什么需要排序
MySQL 执行 GROUP BY 时默认会先对分组字段排序，再逐组聚合。这不是语法要求，而是实现机制：没有索引支撑时，它必须把数据全读出来，写进临时表，再外部排序（Using filesort），最后分组。这个过程 I/O 和 CPU 开销都大。真正要消除的不是“分组”，而是“排序”和“临时表”——索引覆盖就是干这个的。
覆盖索引必须满足三个硬条件
只要缺一个，EXPLAIN 里就会出现 Using temporary 或 Using filesort，说明没走通。
- WHERE 等值条件列必须放在联合索引最左（如
user_id = ?、status = 'active'） - GROUP BY 字段必须紧接其后，且顺序、方向完全一致（如索引是
(status, dept)，就不能写GROUP BY dept, status） -
SELECT中所有字段（含聚合函数依赖的列，如COUNT(*)不需要额外字段，但SUM(amount)需要amount在索引中）必须全部包含在该索引定义里
常见失效场景与对应修复
你以为建了索引就覆盖了？这些细节一错，索引立刻被弃用：
-
SELECT viewed_user_age, COUNT(*) FROM t WHERE user_id = 1 GROUP BY viewed_user_age→ 索引必须是(user_id, viewed_user_age)，不能是(viewed_user_age, user_id)，否则不满足最左前缀 -
SELECT dept, role, SUM(salary) FROM staff GROUP BY dept, role→ 索引得是(dept, role, salary)，只建(dept, role)会导致salary回表，优化器大概率放弃该索引 -
WHERE created_at > '2024-01-01' GROUP BY DATE(created_at)→DATE()是函数，索引失效；MySQL 8.0+ 可建函数索引INDEX (DATE(created_at))，5.7 只能加生成列
ORDER BY NULL 不是补丁，是明确指令
即使索引覆盖完美，MySQL 仍会对 GROUP BY 结果隐式升序排序。如果你不需要这个顺序，加 ORDER BY NULL 不是“绕过问题”，而是告诉优化器：“别排了，我只要分组结果”。这能省掉一次排序开销，尤其在分组数多但每组数据少时效果明显。别把它当成兜底方案——它只在你真不需要排序时才该出现。
