using filesort表示mysql明确放弃索引有序性，必须额外执行内存或磁盘排序；常见原因包括范围查询截断索引、函数表达式破坏有序性、order by字段未命中同一索引最左前缀、方向不一致（5.7不支持混合asc/desc）、select *导致回表后顺序丢失等。
EXPLAIN里出现Using filesort代表什么
它不是“可能慢”，而是MySQL明确放弃了索引的物理顺序，必须额外启动一套排序流程。哪怕只查10行，只要出现Using filesort，就说明排序逻辑已脱离索引结构，进入独立的内存或磁盘排序阶段。
常见触发Using filesort的真实原因
索引存在 ≠ 排序可用。真实场景中，这些写法几乎必然触发Using filesort：
-
WHERE created_at > '2023-01-01' ORDER BY id：范围查询截断索引，created_at之后的字段无法复用有序性 -
ORDER BY UPPER(name)或ORDER BY a + b：函数/表达式让索引值无法对齐原始排序逻辑 -
INDEX (status, created_at)，但查询是WHERE id = 123 ORDER BY created_at：id不在索引中，整个索引根本不会被用于定位或排序 -
SELECT * FROM t ORDER BY created_at：即使created_at有索引，SELECT *强制回表，物理行顺序被打乱，内存里还得重排 - MySQL 5.7 及以前建了
INDEX (a ASC, b DESC)，但ORDER BY a ASC, b DESC仍不走索引——降序索引在8.0+才真正生效
为什么加了索引还是filesort
核心在于「过滤 + 排序」字段是否在同一个索引里连续、方向一致、无跳过：
- 查询是
WHERE status = 1 ORDER BY created_at DESC，就得建INDEX (status, created_at DESC)（注意：5.7要删掉DESC，否则无效） - 如果还要返回
name和email，且不想回表，可扩展为INDEX (status, created_at DESC, name, email)；但别把id加在最前面——主键已隐含在二级索引末尾 -
ANALYZE TABLE t必须执行：优化器可能因统计信息陈旧，直接跳过你刚建的索引
Using temporary和Using filesort同时出现怎么办
这通常意味着MySQL先构建了临时表（比如JOIN后无法流式输出），再对这张临时表排序。此时调大sort_buffer_size基本无效——排序对象是临时表，而临时表本身已因设计问题被迫生成。
优先级很明确：先消灭Using temporary。比如加覆盖索引确保所有JOIN条件 + 排序字段 + 查询字段都在一个索引里，或重构JOIN顺序让驱动表能主导排序；等Using temporary消失后，Using filesort往往也随之消失。
最容易被忽略的一点：max_length_for_sort_data阈值被突破时，优化器会从全字段排序退到rowid排序，看似内存够用，实则引发大量回表IO——这个参数的默认值（1024字节）在现代业务字段宽度下极易被踩中。
