MySQL EXPLAIN 中 filesort 不一定是慢：从排序缓冲区判断真实代价

线上订单列表偶尔从几十毫秒抖到几百毫秒，打开 EXPLAIN 后看到 Extra: Using filesort，很多人第一反应是“必须马上加索引”。这个判断太快了：Using filesort 只说明 MySQL 没有直接用索引完成排序，真正的代价还要看进入排序的行数、是否溢出到临时文件，以及执行时延是否真的集中在排序阶段。

先把 Using filesort 读准确

假设订单表有 created_at、status 和主键 id，列表查询如下：

EXPLAIN SELECT id, status, created_at
FROM orders
WHERE status = 'paid'
ORDER BY created_at DESC, id DESC
LIMIT 20;

如果 Extra 出现 Using filesort，含义是结果行先按 WHERE 条件找到，再额外按 ORDER BY 排序。名字里的 “file” 不代表每次都落盘，也不是某个固定的文件名；它描述的是排序算法阶段。

真正需要先问的是：扫描了多少行？排序了多少行？返回 20 行前是否处理了几十万行？如果 rows 只有几百，排序通常不是第一嫌疑；如果 rows 很大且页面访问频繁，才需要进一步定位。

用执行证据区分小排序和大排序

先看传统计划中的 key、rows 和 Extra，再在可接受的测试数据上运行：

EXPLAIN ANALYZE
SELECT id, status, created_at
FROM orders
WHERE status = 'paid'
ORDER BY created_at DESC, id DESC
LIMIT 20;

重点不是把 Using filesort 从输出里抹掉，而是对照估算行数和实际行数。如果实际只处理少量记录，排序即使存在也可能很便宜；如果实际行数远大于估算值，问题可能先出在统计信息或过滤条件，而非缓冲区大小。

MySQL 官方文档还给出了优化器跟踪中的 filesort_summary，其中可以看到 examined_rows、number_of_tmp_files 和 sort_buffer_size。这组证据比单看一列 Extra 更适合回答“是否真的贵”。

为什么 LIMIT 20 也可能有 filesort

LIMIT 只限制最终返回行数，不必然限制前面的过滤和排序输入。对一个筛出几十万条已支付订单的查询，即使最后只返回 20 行，也可能先处理大量候选行。反过来，如果 status='paid' 只匹配几百行，排序阶段可能完全在内存中完成。

排序缓冲区也不能简单理解成“越大越快”。MySQL 8.0.12 起，排序内存会按需增长到 sort_buffer_size 上限；并发排序很多时，给每个连接设置很大的值会扩大内存峰值。这里别急着改全局配置，先确认排序输入规模和临时文件数量。

优化顺序：先缩小输入，再考虑索引

• 先确认过滤条件是否足够具体，避免把无关订单送进排序阶段。
• 再检查 ORDER BY 与过滤列的组合是否适合当前访问路径，使用新的执行计划验证，而不是只看索引是否“存在”。
• 如果业务允许，缩短时间范围或采用稳定的游标翻页，减少深页扫描。
• 只有在执行证据确认排序本身成为瓶颈时，才评估会话级 sort_buffer_size 调整，并观察并发内存。

加索引也有代价：写入变慢、索引占空间、优化器选择变复杂。一个能消除 Using filesort 的索引，如果让订单写入和其他查询都变差，未必是好交易。

常见问题

Using filesort 是不是一定代表磁盘排序？

不是。它表示存在额外排序阶段；是否使用临时磁盘文件，需要结合排序输入、优化器跟踪和实际运行证据判断。

看到 Using filesort 要不要立刻加索引？

不要。先确认 rows、实际行数和耗时。如果是小结果集，盲目加索引可能只增加写入成本。

sort_buffer_size 调大后会不会解决慢查询？

不一定。它只改变排序可用的会话内存上限，无法修复错误的过滤范围或严重偏差的统计信息，还可能放大并发内存压力。

把一次判断留成检查清单

下次看到 Using filesort，按“扫描范围—实际行数—临时文件—排序耗时—并发内存”的顺序核对。能证明排序输入大且确实耗时，再动查询或索引；只有一行 Extra 时，先别把它当成故障结论。