Using filesort 表示 MySQL 放弃索引有序性而需额外排序，主因是索引字段顺序未按「等值→范围→排序」对齐、ORDER BY 方向/表达式不匹配、SELECT 未覆盖索引字段或优化器未选用索引。
EXPLAIN 中出现 Using filesort 不代表 MySQL 真的写了磁盘文件，而是它放弃了索引的天然有序性，必须把数据捞出来再额外排序——无论内存还是临时表，都意味着 CPU 和 IO 开销陡增，尤其配合 LIMIT 偏移时，性能会断崖下跌。
索引字段顺序没对齐 WHERE + ORDER BY 逻辑
这是最常见也最容易被忽略的根本原因。MySQL 要用同一个索引同时完成过滤和排序，字段顺序必须严格按「等值条件 → 范围条件 → 排序字段」排列，中间不能跳、不能反、不能被截断。
-
WHERE status = 'active' ORDER BY created_at DESC→ 正确索引是INDEX (status, created_at)；建(created_at)或(created_at, status)都无效 -
WHERE user_id = 100 AND age > 25 ORDER BY score→ 可用INDEX (user_id, age, score)，因为age是范围，score紧随其后仍保持局部有序 -
WHERE user_id > 100 ORDER BY age→ 即使有(user_id, age)索引，age也不再全局有序，必然Using filesort
ORDER BY 方向或表达式导致索引失效
方向不一致、函数包裹、字段类型隐式转换，都会让排序无法走索引。
- MySQL 5.7 及以前：索引
(a, b)全为 ASC，但查询写成ORDER BY a ASC, b DESC→ 必然Using filesort；8.0+ 支持INDEX (a ASC, b DESC)，但必须显式定义 -
ORDER BY UPPER(name)、ORDER BY created_at + INTERVAL 1 DAY→ 索引完全失效 -
WHERE phone = 13800138000（数字）而phone是VARCHAR→ 隐式转换导致索引跳过
SELECT 字段没覆盖，被迫回表破坏有序性
即使索引结构完全匹配 WHERE 和 ORDER BY，只要 SELECT 包含未被索引覆盖的字段（比如 SELECT * 或 content），MySQL 就得回表取完整行——而回表后的数据天然无序，排序动作照常发生。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 查询
SELECT id, name, created_at FROM users WHERE status = 'active' ORDER BY created_at DESC→ 建INDEX (status, created_at, id, name)可避免回表，Extra才会显示Using index -
TEXT、BLOB字段不能建索引，覆盖索引里必须排除它们 - 别盲目把所有字段塞进索引——空间膨胀快，写入变慢，收益反而下降
索引存在 ≠ 被选用，得验证优化器是否真用了它
建了索引却还看到 Using filesort，先别急着改结构，检查优化器有没有真正选中它。
- 执行
ANALYZE TABLE table_name更新统计信息，尤其大批量导入后，旧统计会导致成本误判 - 用
EXPLAIN SELECT ... USE INDEX(idx_name) ...强制指定索引，如果Using filesort消失，说明优化器主动绕开了你建的索引 - 对比
rows预估值和实际扫描行数，偏差过大（比如预估 100 行，实际扫 10 万行）就是统计不准或选择性误判
真正难的不是建索引，而是让索引结构和查询模式严丝合缝地咬合——少一个等值字段、多一个函数、错一个方向、漏一个覆盖字段，Using filesort 就不会消失。它不是警告，是明确告诉你：这条查询路径，索引没接上。
