在MySQL中，当查询带有ORDER BY子句时，如果排序列无法利用索引的有序性，数据库就不得不进行额外的排序操作，称为filesort。随着数据量增长，filesort可能成为慢查询的主要元凶。理解MySQL如何执行排序，是优化的第一步。
下面的内容将围绕执行计划分析、索引设计、缓冲区调整以及查询改写展开，帮助开发者定位并解决ORDER BY带来的性能瓶颈。
一、理解MySQL的排序机制与执行计划
MySQL在执行带ORDER BY的查询时，通常有两种获得有序结果集的方式。第一种是索引排序，即查询能够利用某个索引的有序性直接按顺序读取数据，无需额外排序；第二种是文件排序（filesort），当无法利用索引顺序时，MySQL会将需要排序的数据读取到排序缓冲区，在内存或磁盘上完成排序后再返回结果。filesort并不一定真的写文件，如果数据量小于sort_buffer_size，排序可以在内存中完成，但即便在内存中排序，其CPU开销也不容小觑。
要判断一条ORDER BY查询是否走了filesort，可以使用EXPLAIN查看执行计划。重点关注Extra列，如果出现Using filesort，说明发生了额外排序；如果出现Using index，则可能走了覆盖索引而避免了回表。例如下面这条查询：
EXPLAIN SELECT id, title, create_time FROM articles WHERE status = 1 ORDER BY create_time DESC;
如果status列上没有合适的索引，或者索引不支持按create_time排序，Extra列中很可能出现Using filesort。此时即使查询结果集不大，随着表数据量增加，排序代价也会线性甚至超线性增长。观察执行计划是优化的起点，只有明确知道排序发生在哪个环节，才能对症下药。
还需要注意，filesort并不总是坏事。对于小结果集，内存排序开销很低，可能比强制走一个不理想的索引更高效。因此在优化前，应结合行数、排序数据宽度和实际执行时间来综合判断，不要一看到Using filesort就盲目加索引。
二、设计高效索引避免filesort
优化ORDER BY最直接有效的方法就是让查询走索引排序。索引本身是按照列值有序组织的，如果查询的ORDER BY顺序与某个索引的列顺序一致，MySQL就可以直接沿索引扫描返回有序数据，免去排序步骤。这里的关键是遵循最左前缀原则，并且WHERE条件和ORDER BY条件要能够组合起来利用同一个联合索引。
假设articles表经常执行这样的查询：按status过滤并按create_time倒序排列。此时可以创建一个联合索引：
ALTER TABLE articles ADD INDEX idx_status_create (status, create_time);
对于查询WHERE status = 1 ORDER BY create_time DESC，这个索引非常合适。因为status是等值条件，之后扫描到的create_time自然有序，MySQL可以沿索引从大到小读取数据，完全避免filesort。如果索引列顺序反过来，比如(create_time, status)，虽然create_time有序，但status过滤会破坏顺序，无法直接利用索引完成排序。对于多个排序字段，例如ORDER BY col1, col2，联合索引(col1, col2)也能很好地支持。
需要注意的是，MySQL 8.0之前对于混合ASC和DESC的排序，可能会让索引失效；MySQL 8.0引入了降序索引，可以显式创建DESC索引来支持。另外函数操作、隐式类型转换、范围条件后的排序列等都会导致索引排序不可用。设计索引时要查看查询模式，尽量让WHERE条件为等值，排序列紧随其后。
三、filesort缓冲区调优与查询改写
当无法通过索引完全避免排序时，filesort会成为必要操作。此时优化目标是减少排序数据量和提高排序效率。一个有效手段是避免SELECT *，只查询业务需要的列。因为filesort的排序对象是整行数据或指定列，行数据越宽，排序缓冲区能容纳的行数越少，越容易溢出到磁盘。如果只查询少量列，并且这些列都包含在某个索引中，甚至可以采用覆盖索引，排序直接在索引树上完成。
MySQL提供了sort_buffer_size参数来控制每个会话用于排序的内存缓冲区大小。对于需要频繁排序的应用，适当增大该值可以让更多排序在内存中完成，减少磁盘I/O。但也不宜设置过大，否则多个并发排序会占用大量内存。在MySQL 8.0中，旧版本参数max_length_for_sort_data已被移除，排序算法由优化器自动选择，调优重点转向sort_buffer_size和合理的查询设计。
对于深分页场景，例如ORDER BY create_time DESC LIMIT 1000000, 10，即使走了索引，MySQL也需要读取并丢弃前100万行，代价很高。此时可以改写为延迟关联：先在子查询中通过覆盖索引取出分页的id，再回表取完整数据。示例：
SELECT a.id, a.title, a.content
FROM articles a
INNER JOIN (
SELECT id FROM articles
WHERE status = 1
ORDER BY create_time DESC
LIMIT 1000000, 10
) t ON a.id = t.id;
这样外层只需要回表10次，子查询只扫描索引，性能会有数量级提升。
四、监控与特殊场景注意事项
优化不是一次性的，需要持续监控慢查询并观察执行计划的变化。开启MySQL慢查询日志，配合pt-query-digest或Percona Monitoring and Management等工具，可以快速定位含有Using filesort的高频查询。同时，定期使用EXPLAIN ANALYZE（MySQL 8.0.18以上）可以获取实际执行时间和排序信息，比传统EXPLAIN更准确。
在一些特殊场景下，ORDER BY会伴随GROUP BY、UNION或子查询出现。例如UNION操作默认会去重并排序，如果不需要去重，应使用UNION ALL；GROUP BY后若结果已有序，可以利用该顺序避免再次排序。另外，对于海量日志或历史数据表，可考虑分区裁剪，让查询只扫描相关分区，减少参与排序的行数。
最后要强调，ORDER BY优化没有放之四海而皆准的方案，需要结合表结构、索引、查询模式和业务需求综合判断。先通过EXPLAIN确认排序方式，再决定是增加索引、改写查询还是调整缓冲区参数。只有持续验证与调优，才能保证数据库在高并发下的稳定响应。
通过上述四个维度的分析和调整，绝大多数ORDER BY慢查询都可以得到有效改善。
MySQL ORDER BY优化排序查询性能索引排序修改时间：2026-08-24 01:39:40