MySQL排序性能直接影响查询响应速度，尤其在涉及
ORDER BY、
GROUP BY、
DISTINCT等操作时，容易产生“排序文件”（sort files），即使用磁盘临时文件进行排序。优化这类场景能显著提升系统效率。
理解排序文件的产生
当MySQL无法在内存中完成排序时，会将数据分批写入磁盘临时文件，再进行归并排序。这个过程称为“filesort”，即使名字叫filesort，也不一定代表性能差，但频繁使用磁盘会拖慢查询。
常见触发场景包括：
排序字段没有索引 排序字段虽有索引，但查询条件或联合方式导致索引无法覆盖排序 排序数据量超过sort_buffer_size限制
合理使用索引加速排序
最有效的优化手段是让排序走索引，避免filesort。
建议： 为常用排序字段建立索引，如CREATE INDEX idx_created ON orders(created_at);</li> <li>复合查询时使用联合索引，满足“最左前缀”原则，例如：<code>WHERE status = 'paid' ORDER BY created_at，可建
(status, created_at)索引 尽量使索引覆盖查询字段（覆盖索引），减少回表
可通过
EXPLAIN查看执行计划，若
Extra列出现
Using filesort，说明未走索引排序。
调整排序缓冲区大小
MySQL使用
sort_buffer_size控制每个连接用于排序的内存空间。过小会导致频繁磁盘写入。 优化方法： 适当调大
sort_buffer_size（如设置为2M~8M），但不宜过大，因为该内存是“每连接”分配，可能浪费资源 避免全局设太大，可在会话级对关键查询临时调整：
SET SESSION sort_buffer_size = 4194304;
注意：此参数不能动态设置为超过1GB，且只作用于单个排序操作。
减少参与排序的数据量
从源头减少需要排序的行数，是最直接的优化思路。
做法包括： 在WHERE条件中尽早过滤无关数据 避免
SELECT *，只查必要字段，降低排序记录大小 分页查询时使用
LIMIT，配合索引跳过排序开销 大数据集排序考虑使用“游标分页”（基于上一页最后一条ID继续查），而非
OFFSET
监控与分析排序行为
通过状态变量了解排序性能：
SHOW STATUS LIKE 'Sort%';Sort_rows：已排序的行数
Sort_scan：通过扫描表完成的排序次数
Sort_range：使用范围扫描后排序的次数
Sort_merge_passes：排序过程中归并的次数，过高说明内存不足
若
Sort_merge_passes频繁增长，应考虑增加
sort_buffer_size或优化索引。
基本上就这些。核心是优先用索引避免排序，其次是合理配置内存，再结合查询设计控制数据规模。不复杂但容易忽略细节。
