在高并发、大数据量的业务场景中，SQL 查询性能直接影响系统整体响应速度。其中，ORDER BY（排序） 和 GROUP BY（分组） 是最常见但也最容易引发性能瓶颈的操作。本文将深入探讨 MySQL 中排序与分组的执行机制，并提供一系列实用的优化策略。
一、为什么 ORDER BY / GROUP BY 容易成为性能瓶颈
MySQL 在执行包含 ORDER BY 或 GROUP BY 的查询时，若无法利用索引完成排序或分组，就会触发 “Using filesort” 或 “Using temporary; Using filesort” ，这意味着：
- 临时表（temporary table） ：用于存储中间结果；
- 文件排序（filesort） ：在内存或磁盘上对数据进行排序。
这两个操作消耗大量 CPU 和 I/O 资源，尤其在数据量大时，可能导致查询耗时从毫秒级飙升至数秒甚至超时。
二、核心优化原则
1.合理使用复合索引
MySQL 可以利用最左前缀原则的复合索引来避免排序和临时表。
示例：
|
1 2 3 4 5 |
-- 查询：按 user_id 分组，并按 create_time 排序 SELECT user_id, MAX(create_time) FROM orders GROUP BY user_id ORDER BY user_id; |
若存在索引 (user_id, create_time)，则 GROUP BY user_id 可直接利用索引顺序，无需额外排序。
注意：ORDER BY 字段必须与索引顺序一致，且不能跳过中间字段。
2. *避免 SELECT，只取必要字段
当使用 GROUP BY 时，若 SELECT 中包含非分组字段且未聚合，MySQL 5.7+ 默认会报错（sql_mode=ONLY_FULL_GROUP_BY）。更重要的是，返回过多字段会增加临时表大小，拖慢排序。
优化写法：
|
1 2 3 4 5 6 7 8 9 |
-- 好 SELECT user_id, COUNT(*) FROM orders GROUP BY user_id;
-- 避免 SELECT *, COUNT(*) FROM orders GROUP BY user_id; |
3.控制结果集大小（LIMIT 优化）
如果只需前 N 条结果（如分页），务必加上 LIMIT。MySQL 在某些情况下可提前终止排序。
|
1 2 3 4 5 |
SELECT user_id, SUM(amount) FROM orders GROUP BY user_id ORDER BY SUM(amount) DESC LIMIT 10; |
配合索引，可显著减少排序开销。
4.调整排序缓冲区（sort_buffer_size）
对于无法避免的 filesort，适当增大 sort_buffer_size 可让排序完全在内存中完成，避免磁盘 I/O。
建议：仅在会话级别临时调大（如 SET SESSION sort_buffer_size = 4M;），避免全局设置导致内存浪费。
5.避免函数或表达式破坏索引使用
如下写法会导致索引失效：
|
1 2 3 4 |
-- ? 无法使用索引排序 SELECT * FROM users ORDER BY UPPER(name);
-- ? 应在应用层处理，或建立函数索引（MySQL 8.0+ 支持） |
三、MySQL 8.0 的新特性助力优化
- 隐藏索引（Invisible Indexes） ：方便测试索引对排序/分组的影响；
- 降序索引（Descending Indexes） ：支持 INDEX (a ASC, b DESC)，完美匹配复杂排序需求；
- 函数索引（Functional Indexes） ：可对表达式建索引，提升 ORDER BY YEAR(create_time) 等场景性能。
四、实战检查步骤
使用 EXPLAIN 查看执行计划，重点关注：
- Extra 字段是否出现 Using filesort 或 Using temporary；
- key 是否命中预期索引。
若存在 filesort，尝试调整索引顺序或查询结构；
对高频慢查询开启 slow_query_log，持续监控。
五、总结
- 索引是排序与分组优化的核心；
- 尽量让 WHERE → GROUP BY → ORDER BY 的字段顺序与复合索引一致；
- 减少不必要的字段和数据量；
- 善用 MySQL 8.0 新特性提升灵活性。
通过合理设计索引与 SQL 语句，绝大多数 ORDER BY / GROUP BY 性能问题都能迎刃而解。
