假设你正在开发一个电商平台的订单系统，产品经理提出这样的需求：当用户进入"我的订单"页面时，需要按照下单时间的倒序展示最近的20条订单记录。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

参考解答

MySQL的数据排序主要通过两种方式实现：索引排序和文件排序（filesort）。

效率最高的当属索引排序。当我们在ORDER BY子句中使用的字段恰好有索引，并且索引顺序与排序要求完全一致时，MySQL会直接利用索引的有序性返回结果，完全不需要额外的排序操作。在执行计划中，这种方案不会出现"Using filesort"的标记。

其次是文件排序，当无法利用索引时，MySQL会启用filesort机制。这个过程会根据待排序数据量的大小采取不同策略：

内存排序阶段：如果数据量较小，能够放入sort_buffer（由参数sort_buffer_size控制），就在内存中完成排序。内存排序又分为两种模式：单路排序（全字段排序）会直接把查询需要的所有字段都读到sort_buffer中进行排序，排完直接返回，避免**双路排序（rowid排序）**：当单行数据过大时（超过max_length_for_sort_data），只读取排序字段和主键ID到sort_buffer，排序完成后再回表查询其他字段磁盘排序阶段：如果数据量超过sort_buffer容量，MySQL会使用归并排序算法，将数据分批次在内存中排序后写入临时文件，最后再将多个有序文件合并，这个过程会涉及大量磁盘IO，性能较差。

决定采用哪种排序方式的关键因素包括：是否有合适的索引、数据量大小、sort_buffer_size参数、max_length_for_sort_data参数等。因此，在实际优化中，我们应当优先考虑建立合适的索引来避免filesort，如果必须使用filesort，则需要合理调整相关参数以尽量在内存中完成排序。

图片

一、从一个场景说起

假设你正在开发一个电商平台的订单系统，产品经理提出这样的需求：当用户进入"我的订单"页面时，需要按照下单时间的倒序展示最近的20条订单。你很快写出了这样的查询语句：

SELECT order_id, user_id, order_time, total_amount FROM orders WHERE user_id = 10086 ORDER BY order_time DESC LIMIT 20;

这个看似简单的查询，背后却隐藏着MySQL复杂的排序机制。当你用EXPLAIN分析这条SQL时，可能会看到两种截然不同的结果：一种是干净利落，直接走索引；另一种则出现了"Using filesort"，表明使用了文件排序。

这两种情况的性能差异可能达到几十倍甚至上百倍。为什么会有这样的差异？MySQL内部到底是如何处理排序的？下面，我们从最底层的原理开始剖析。

二、索引排序

2.1 索引天然有序

很多开发者都知道索引能加速查询，遇到问题就加索引，因为索引有一个重要特性：索引本身就是有序的。

在InnoDB存储引擎中，索引采用B+树结构。这种树的叶子节点按照索引键值从左到右串联成一个有序链表。当你在order_time字段上建立索引后，MySQL实际上已经维护了一个按时间排序的"目录"。

想象一下图书馆的书籍编目系统：如果图书已经按照出版时间在书架上从左到右排列好了，当读者要求"给我最近出版的20本书"时，管理员只需要从最右边取20本即可，完全不需要把所有书搬出来重新排序。

2.2 触发索引排序的条件

但索引排序并非万能钥匙，它的触发需要满足严苛的条件：

1）索引列顺序必须与ORDER BY顺序完全匹配

假设你建立了一个联合索引INDEX idx_user_time(user_id, order_time)。这个索引的存储结构是先按user_id排序，user_id相同时再按order_time排序。

此时如果你的查询是：

--  √ 能用索引排序
WHERE user_id = 10086 ORDER BY order_time
--  × 不能用索引排序
ORDER BY order_time, user_id 
-- 顺序颠倒

2）排序方向必须一致

--  √ 都是升序或都是降序
ORDER BY order_time DESC, status DESC
--  × 方向不一致
ORDER BY order_time DESC, status ASC

MySQL 8.0之前的版本无法利用索引处理方向不一致的排序，因为索引只能单向扫描。就像电梯要么向上要么向下，不能一边上升一边下降。在MySQL 8.0之后的版本对索引排序能力进行了重要优化，支持利用索引处理方向不一致的排序（即对联合索引中不同字段使用ASC和DESC混合排序），无需额外的文件排序（filesort）。

8.0之前的限制：联合索引的物理存储是"单向有序"的（例如(a ASC, b ASC）），只能按索引定义的方向扫描。如果查询中排序方向与索引定义不一致（如ORDER BY a ASC, b DESC），索引无法直接满足排序需求，会触发文件排序。

8.0及之后的优化：引入了"降序索引"（descending index）支持，允许在创建联合索引时为每个字段指定排序方向（ASC或DESC），且优化器能利用这类索引处理混合方向的排序。

例如，若创建索引INDEX idx_mixed(a ASC, b DESC)，则查询ORDER BY a ASC, b DESC可直接通过索引扫描返回有序结果。即便索引定义为全ASC（如(a ASC, b ASC）），8.0优化器也能反向扫描索引（从后往前读），来满足ORDER BY a DESC, b DESC这类同方向倒序的需求，无需文件排序。

注意事项：降序索引仅支持InnoDB存储引擎。混合排序的字段顺序仍需遵循联合索引的"最左前缀原则"（如索引(a, b)可支持ORDER BY a ASC, b DESC，但不支持ORDER BY b ASC, a DESC）。

3）WHERE条件与ORDER BY字段的配合

当查询既有WHERE过滤又有ORDER BY排序时，索引必须同时满足两者的需求。最优情况是建立覆盖索引，把WHERE、ORDER BY、SELECT涉及的字段都包含进去。

2.3 优化器的权衡

即便满足了上述所有条件，MySQL优化器仍然可能选择不用索引排序。这是因为优化器会计算"成本"。

假设你的查询需要返回100万条数据，虽然有索引可以保证有序，但每条数据都需要回表查询（因为索引中只有排序字段，其他字段在主键索引上）。优化器一算：这得回表100万次！还不如直接全表扫描，把所有数据读到内存里排序一次。

这就是为什么你会看到一些"明明有索引却不用"的诡异现象。优化器并非不智能，而是在做综合权衡。

三、文件排序

3.1 filesort的触发时机

当下面任何一个条件成立时，MySQL就会放弃索引排序，启动filesort机制：

排序字段没有索引索引无法覆盖所有查询字段（需要大量回表）ORDER BY使用了表达式或函数（如ORDER BY YEAR(order_time)）多表关联查询的复杂排序优化器评估索引排序成本过高

在执行计划的Extra列中出现"Using filesort"，就是MySQL在告诉你："我得自己排序了"。

3.2 sort_buffer：排序的临时工作区

MySQL会为每个需要排序的查询分配一块内存区域，叫做sort_buffer（排序缓冲区）。这块内存的大小由参数sort_buffer_size控制，默认值通常是256KB。

这内存是会话级别的，意味着每个客户端连接都有自己独立的sort_buffer。如果你的系统有1000个并发连接，每个连接的sort_buffer设置为4MB，理论上就需要4GB内存来支撑排序操作。

sort_buffer的工作流程像这样：

MySQL根据WHERE条件筛选出需要排序的记录将相关字段读入sort_buffer在sort_buffer中使用快速排序算法进行排序返回排序后的结果

关键问题来了：如果数据量太大，sort_buffer装不下怎么办？

3.3 单路排序

这是MySQL默认采用的排序方式。它的核心思想是：把查询需要的所有字段都读到sort_buffer中，排序完成后直接返回，不需要再回表。

假设你的查询是：

SELECT order_id, user_id, order_time, total_amount, status FROM orders WHERE user_id = 10086 ORDER BY order_time DESC LIMIT 20;

单路排序的执行过程：

扫描定位：根据user_id = 10086的条件，找到所有符合条件的记录（假设有5000条）字段提取：对每条记录，提取order_id、user_id、order_time、total_amount、status这五个字段的值装入缓冲区：将这5000条记录的五个字段全部装入sort_buffer如果5000条数据占用空间小于sort_buffer_size（比如256KB），全部装入内存如果超过了，就需要使用外部排序内存快速排序：在sort_buffer中对这5000条数据按order_time进行快速排序取出结果：排序完成后，取前20条返回给客户端

这种方式的优点是一次性完成，不需要回表，缺点是占用内存较大。如果单行数据很宽（比如包含大字段），很容易超过sort_buffer限制。

3.4 双路排序（rowid排序）：空间换时间

当单行数据太大时，MySQL会切换到双路排序模式。判断标准是参数max_length_for_sort_data，默认值是4096字节。

如果参与排序的单行数据长度超过这个阈值，就会触发双路排序。

双路排序的思路是：只把排序字段和主键ID读到sort_buffer，排序完成后再回表查询其他字段。

还是刚才的例子，执行过程变成：

扫描定位：找到user_id = 10086的5000条记录提取：对每条记录，只提取order_time（排序字段）和order_id（主键）两个字段装入缓冲区：将5000条记录的两个字段装入sort_buffer

因为只有两个字段，占用空间大大减少，更容易在内存中完成排序。

内存快排：按order_time对这5000条数据进行快速排序取出前20：排序完成后，取出前20条的order_id回表查询：根据这20个order_id，回到主键索引上查询完整的记录（包括user_id、total_amount、status）返回结果：将查询到的20条完整记录返回给客户端

这种方式的优点是占用内存小，更容易在内存中完成排序，缺点是需要额外的回表操作。

不过仔细想想，回表只针对最终返回的20条数据，所以这个代价是可以接受的。如果没有LIMIT限制，需要返回全部5000条，那回表代价就很高了。

相关攻略

热门推荐