Using filesort 表示MySQL无法利用索引有序性而需额外排序，不必然落盘或低效；常见原因包括ORDER BY字段未命中索引、复合索引顺序不匹配、含范围查询或非覆盖字段等。
Using filesort 表示 MySQL 正在做外部排序
Using filesort 出现在 EXPLAIN 的 Extra 列中，不代表用了磁盘文件，也不代表一定慢——它只是说明 MySQL 无法利用索引的物理顺序直接返回有序结果，必须额外启动一套排序逻辑。
这套逻辑优先使用内存中的 sort_buffer_size，只有当待排序数据量超过该值时，才会落盘生成临时归并文件（tmpdir 下的 MY**** 文件），触发真正的“file sort”。
常见触发场景包括：
-
ORDER BY字段未命中索引，或索引顺序与ORDER BY不一致（比如索引是(a,b)，却ORDER BY b,a） - 同时
SELECT非索引覆盖字段 +ORDER BY索引字段，导致无法用索引下推排序 - 查询含
LIMIT但优化器判断走索引扫描成本高于全表 + 排序（尤其小表或高偏移量时）
SortBuffer 是怎么工作的？关键看 two-pass 还是 single-pass
MySQL 排序分两种模式，由 max_length_for_sort_data 参数和实际字段长度共同决定：
-
single-pass 模式：把所有需要的字段（
SELECT列 +ORDER BY列）一次性读入sort_buffer，排序后直接输出。优点是只需一次表扫描；缺点是容易撑爆sort_buffer，触发磁盘归并 -
two-pass 模式：只把
ORDER BY列和主键（或 rowid）读入sort_buffer，排序后按主键回表取其余字段。优点是内存压力小；缺点是多一次随机 IO（回表）
你可以通过 SHOW VARIABLES LIKE 'max_length_for_sort_data' 查看当前阈值，默认 1024 字节。如果 ORDER BY 字段 + 主键长度 ≤ 该值，大概率走 single-pass；否则 fallback 到 two-pass。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
验证方式：开启 profiling 后执行 SQL，再查 SHOW PROFILE FOR QUERY N，观察 Sorting result 和 Copying to tmp table 阶段耗时占比。
为什么加了索引还出现 Using filesort？
索引存在 ≠ 排序可跳过。以下情况即使有索引，EXPLAIN 仍会显示 Using filesort：
- 复合索引顺序不匹配：索引为
(user_id, create_time)，但查询是ORDER BY create_time DESC（缺少前导列user_id过滤） -
WHERE条件用了范围查询（如user_id > 100），导致索引只能用到前缀，后续ORDER BY字段无法复用有序性 -
SELECT中包含TEXT/BLOB字段，或字段总长度超max_length_for_sort_data，迫使优化器放弃 single-pass，而 two-pass 必须排序 - 使用了函数或表达式：
ORDER BY UPPER(name)、ORDER BY a+b，索引失效
注意：GROUP BY 在 MySQL 8.0+ 默认不隐式排序，但若显式加了 ORDER BY，依然可能触发 Using filesort。
真正影响性能的是什么？别只盯着 Extra 字段
Using filesort 本身不是性能杀手，背后的真实瓶颈往往藏在其他地方：
-
rows值过大：表示排序前要扫描太多行，应优先优化WHERE条件或加覆盖索引 -
type是ALL或index：全表/全索引扫描带来巨大 I/O，排序只是“最后一根稻草” -
key为空：没走任何索引，排序只是表象，根源是缺失驱动索引 - 并发高时
sort_buffer被争抢：每个连接独占一份 buffer，全局设置过大易引发内存抖动
最常被忽略的一点：业务是否真的需要数据库排序？比如分页拉取最新 20 条，用主键倒序 + LIMIT 可完全避免 Using filesort；又比如报表类排序，移到应用层用流式处理反而更可控。
