MySQL EXPLAIN 怎样看懂 filesort 的来源

看懂 Using filesort 的来源，要把“用什么方式找行”和“这些行是否已经符合 ORDER BY 顺序”分开判断。它表示计划包含额外排序，不能仅凭这个词认定发生了磁盘排序，也不能认定 WHERE 没有使用索引。先定位排序所属查询块，再比较索引列序、等值条件和排序表达式。

MySQL 官方地址：https://www.mysql.com/

本文参考文档：https://dev.mysql.com/doc/refman/8.4/en/order-by-optimization.html

先把排序信号定位到查询块

把触发慢查询的实际参数、ORDER BY、LIMIT、表结构和索引定义一起保存。不要用去掉过滤条件的简化 SQL 代替原查询，否则可能改变访问路径。传统 EXPLAIN 的 key 与 Extra 需要一起读：前者说明选择的访问索引，后者的 Using filesort 说明仍有额外排序。

多表、派生表和子查询可能具有多个查询块。使用 EXPLAIN FORMAT=JSON 查看 using_filesort 所在的层级，并把该层级与具体 ORDER BY 对应起来。不要把某一层的排序，直接归咎于结果中看到的任意一张表。显式指定输出格式也能避免把不同格式的字段名混在一起。

用订单查询找出索引中间的分组

假设租户订单页要求显示该租户所有状态的最近订单。现有索引是 (tenant_id, status, created_at)。tenant_id 被固定后，索引仍先按 status 分组，每个状态组内部再按 created_at 排列；这不能直接提供跨状态的时间顺序。

-- 在独立测试库创建示例表，不要在业务表上直接照搬 DDL。
CREATE TABLE order_sort_demo (
    id BIGINT NOT NULL PRIMARY KEY,
    tenant_id BIGINT NOT NULL,
    status TINYINT NOT NULL,
    created_at DATETIME NOT NULL,
    KEY idx_tenant_status_created (tenant_id, status, created_at)
) ENGINE=InnoDB;

-- status 没有固定，索引中的状态分组会打断全局时间顺序。
EXPLAIN FORMAT=TRADITIONAL
SELECT id, created_at
FROM order_sort_demo
WHERE tenant_id = 42
ORDER BY created_at DESC
LIMIT 30;

-- JSON 用于定位排序所属层级，实际计划以当前数据为准。
EXPLAIN FORMAT=JSON
SELECT id, created_at
FROM order_sort_demo
WHERE tenant_id = 42
ORDER BY created_at DESC
LIMIT 30;

这是供读者在测试库构造的例子，没有预置或虚构 EXPLAIN 输出。空表、小表和不同数据分布可能导致不同选择。这里确定的是排序需求与索引结构不一致；即使该索引有助于定位租户数据，也不代表能直接满足这个 ORDER BY。

按排序目标选择候选改动

如果业务本来只看状态1，增加真实的等值条件后，索引前两列都固定，剩下的时间列才有机会提供所需顺序。如果业务要看所有状态，就保留原查询，评估 (tenant_id, created_at) 作为候选。两种改动分别解决不同任务，不能互换。

-- 仅在业务确实限定状态时使用，不能为了计划好看而改查询含义。
EXPLAIN FORMAT=TRADITIONAL
SELECT id, created_at
FROM order_sort_demo
WHERE tenant_id = 42 AND status = 1
ORDER BY created_at DESC
LIMIT 30;

-- 跨状态时间排序的候选索引，先在测试环境评估。
CREATE INDEX idx_tenant_created
ON order_sort_demo (tenant_id, created_at);

-- 保持原查询不变，再查看候选索引是否被选择。
EXPLAIN FORMAT=TRADITIONAL
SELECT id, created_at
FROM order_sort_demo
WHERE tenant_id = 42
ORDER BY created_at DESC
LIMIT 30;

除了中间列没有固定，还应查看 ORDER BY 是否使用表达式、排序方向与索引方向是否匹配、排序列是否只有前缀索引，以及连接方式是否允许利用目标表的顺序。普通列索引不能自动等同于对该列任意表达式的排序索引。不要靠把索引列清单抄成 ORDER BY 来消除信号，那可能改变用户看到的顺序。

候选索引也不保证一定被选择。优化器还要比较查找、读取所需列等整体代价；过滤收益较好的路径加一次排序，有时比为顺序扫描更多数据更合适。需要稳定分页时，还应明确同时间记录的次序，增加唯一排序键会同时改变需要评估的索引需求。

保留回退路径再比较整体代价

先保存原 SQL 与索引定义，再在代表性数据上比较同一查询的计划和整体耗时，不能只比较 Extra 是否少了一个词。本文的 EXPLAIN 用于估计计划；如另外选择 EXPLAIN ANALYZE，应认识到它会实际执行查询，并在合适环境控制负载。

若测试中新索引没有带来收益，可以撤销本次新增的候选；如果改的是查询文本，则保留原查询作为切回版本。不要顺手删除旧索引，它可能仍被其他查询使用。上线索引变更还需结合表规模、DDL影响和写入成本安排。

-- 仅撤销本次在测试示例中新建的候选索引。
DROP INDEX idx_tenant_created ON order_sort_demo;

后续观察重点是目标 SQL 的延迟和读取规模，而不是整台服务器有没有任何 filesort。filesort 可以在内存完成，单独的 EXPLAIN 标记不能回答是否使用临时磁盘文件。也不要将 Using temporary 与 Using filesort 当成同一个信号；它们描述不同的处理需求。

排查速查表与相关问题

LIMIT 30 能保证只排序30行吗？

不能。LIMIT 限制返回数量，实际访问和参与排序的候选范围还取决于过滤与计划，不能从页大小推导处理量。

Using index 代表没有 filesort 吗？

不能。它主要描述覆盖索引读取，排序顺序是否满足需要另外判断。

应该先调大 sort_buffer_size 吗？

应先定位排序来源和参与数据范围。调整缓冲区不会让不匹配的索引顺序变成匹配，也应结合并发排序的资源代价评估。