Using filesort 并不等于排序失败，它表示 MySQL 无法直接按照索引顺序返回查询结果，因此需要执行额外排序；具体性能表现主要取决于排序是在内存中完成（sort_buffer 足够）还是已经写入磁盘临时文件（number_of_tmp_files > 0）。
EXPLAIN里出现 Using filesort 就代表排序失败了吗
并不是。Using filesort 在 MySQL EXPLAIN 中真正表达的是：数据库无法利用索引中已有的顺序直接输出结果，因此必须额外执行一次排序操作。它本身并不等同于“查询性能一定很差”，但在很多场景下，确实意味着这条 SQL 没有走到最优执行路径。决定性能差异的关键是，这次文件排序究竟是在内存中快速完成（sort_buffer 足够大），还是已经被迫写入磁盘临时文件（number_of_tmp_files > 0）。前者通常仍可控制在毫秒级，后者一旦涉及磁盘 I/O，响应时间往往就会明显波动。
为什么有索引还触发 filesort
很多人容易误以为“只要 ORDER BY 字段上有索引，就一定不会出现 Using filesort”。实际上，MySQL 排序触发 filesort 的常见场景非常多：
SELECT *+ 主键索引：虽然主键索引可以定位数据行，但SELECT *需要回表读取全部列，回表过程可能打乱原有顺序，最终 MySQL 仍然需要把数据取出后再重新排序- 联合索引顺序不匹配：例如索引为
(status, created_at)，但 SQL 写成ORDER BY created_at—— 如果缺少最左列status的过滤条件，索引就无法按照created_at实现有序扫描 - 排序方向混用：索引定义为
(a ASC, b ASC)，但查询使用ORDER BY a ASC, b DESC，在 MySQL 8.0 之前这类写法无法利用索引顺序，通常会直接退化为 filesort - 对排序字段使用函数：如
ORDER BY UPPER(name)或ORDER BY DATE(created_at)，字段值经过函数计算后，原有索引顺序被破坏，无法直接用于排序
如何确认是不是覆盖索引问题
判断是否属于覆盖索引不足导致的排序问题，核心还是看 EXPLAIN 中 key 与 Extra 的组合表现：
- 如果
key显示已经使用了某个索引（如PRIMARY或idx_status_created），但Extra里依旧出现Using filesort→ 大概率说明查询字段没有被索引完全覆盖，导致回表后再排序 - 可尝试把
SELECT *改为只查询索引中已经包含的字段。例如索引是(status, id, name)，那么可以写成SELECT id, name FROM t WHERE status = 1 ORDER BY id - 设计覆盖索引时，应优先把
WHERE过滤列放在前面，再紧跟ORDER BY排序列，并保证排序方向一致；同时避免中间跳列或排序方向不统一，否则索引排序能力会被削弱
LIMIT 偏移量大时 filesort 更要命
像 ORDER BY id LIMIT 10000, 20 这样的 SQL，看起来最终只返回 20 行，但 MySQL 实际上必须先找到并处理前 10000 行满足条件的数据——即使 id 上已经有索引，也必须先“跳过足够多的记录”后才能返回结果。这会带来几个直接问题：
sort_buffer并不是只为 20 行准备，而往往需要至少容纳 10020 行数据，甚至更多，具体还取决于筛选条件和命中比例- 一旦数据量超过
sort_buffer_size，排序过程就可能落盘，生成多个临时文件，后续归并排序的开销会迅速上升 - 在 RR 隔离级别下，这类长时间扫描还会扩大一致性读快照范围，进一步增加锁等待和查询抖动的风险
很多时候真正拖慢查询的，并不是 MySQL 排序动作本身，而是“为了拿到这一页数据，不得不先扫描大量记录”这个前提。相比单纯调大 buffer，更有效的 SQL 优化方式通常是改成游标分页，例如 WHERE id > last_seen_id ORDER BY id LIMIT 20。
