在高并发、大数据量的业务场景中，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 可以利用最左前缀原则的复合索引来避免排序和临时表。

示例：

若存在索引 (user_id, create_time)，则 GROUP BY user_id 可直接利用索引顺序，无需额外排序。

注意：ORDER BY 字段必须与索引顺序一致，且不能跳过中间字段。

2. *避免 SELECT，只取必要字段

当使用 GROUP BY 时，若 SELECT 中包含非分组字段且未聚合，MySQL 5.7+ 默认会报错（sql_mode=ONLY_FULL_GROUP_BY）。更重要的是，返回过多字段会增加临时表大小，拖慢排序。

优化写法：

3.控制结果集大小（LIMIT 优化）

如果只需前 N 条结果（如分页），务必加上 LIMIT。MySQL 在某些情况下可提前终止排序。

配合索引，可显著减少排序开销。

4.调整排序缓冲区（sort_buffer_size）

对于无法避免的 filesort，适当增大 sort_buffer_size 可让排序完全在内存中完成，避免磁盘 I/O。

建议：仅在会话级别临时调大（如 SET SESSION sort_buffer_size = 4M;），避免全局设置导致内存浪费。

5.避免函数或表达式破坏索引使用

如下写法会导致索引失效：

三、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 性能问题都能迎刃而解。