Using filesort不是SQL错误，而是MySQL无法利用索引有序性完成排序，需额外内存或磁盘排序；常见原因包括ORDER BY字段未命中索引最左前缀、范围条件截断、函数表达式、混合ASC/DESC、非驱动表排序或未覆盖SELECT字段。
出现 Using filesort 不代表 SQL 写错了，而是 MySQL 没法靠索引直接返回已排序的数据——它必须把符合条件的行先捞出来，再额外排一次序。这步操作会吃 CPU、占内存、拖慢查询，尤其当 rows 值大或带 LIMIT 偏移时，性能断崖下跌。
ORDER BY 字段没走索引的典型场景
最常见的情况是：WHERE 条件用了索引，但 ORDER BY 字段完全不在该索引里，或者顺序不匹配。
-
WHERE status = 1用了INDEX(status)，但ORDER BY created_at没索引 → 必然Using filesort - 建了
INDEX(a, b)，却写ORDER BY b, a→ 违反最左前缀，索引对排序无效 -
ORDER BY UPPER(name)或ORDER BY DATE(created_at)→ 函数表达式让索引失效 -
WHERE a > 10 ORDER BY b→a是范围条件，b在索引中虽紧随其后，但全局有序性已被破坏（MySQL 5.7 及以前）
联合索引字段顺序怎么排才真正生效
关键不是“有没有索引”，而是索引结构能否同时支撑 WHERE 过滤和 ORDER BY 排序。顺序必须严格遵循：等值字段 → 范围字段 → 排序字段，中间不能跳、不能反、不能插其他无关列。
- 查询：
SELECT id, name FROM users WHERE status = 'active' AND age BETWEEN 18 AND 30 ORDER BY created_at DESC
正确索引：INDEX(status, age, created_at)
错误索引：INDEX(status, created_at, age)（age范围条件会截断created_at的局部有序性） - 多个排序字段方向要一致：
ORDER BY a ASC, b DESC在 MySQL 8.0+ 可用INDEX(a ASC, b DESC)；5.7 及以前只能全 ASC 或全 DESC，否则部分字段无法利用 - 如果只查
id, name, created_at，可扩展为INDEX(status, age, created_at, id, name)实现覆盖，避免回表后数据乱序
为什么加了索引还是出现 Using filesort
索引存在 ≠ 被选用。优化器可能因为统计不准、隐式转换或成本误判而绕开你建的索引。
- 执行
ANALYZE TABLE users更新统计信息，尤其在大批量导入后 - 检查类型是否严格匹配：
WHERE phone = 13800138000（数字） vsphone VARCHAR(20)→ 隐式转换导致索引失效 - 用
FORCE INDEX(idx_name)临时验证：如果加了之后Using filesort消失，说明优化器主动弃用了它，得看rows预估是否严重偏差 - JOIN 场景下对非驱动表字段排序（如
JOIN orders o ON u.id = o.user_id ORDER BY o.created_at），即使o.created_at有索引，也可能因驱动表选择问题导致排序无法走索引
最容易被忽略的是 GROUP BY —— MySQL 8.0 之前默认隐式排序，哪怕 SQL 没写 ORDER BY，也会触发 Using filesort。这种“看不见的排序”往往在压测时才暴露。
