Using filesort说明MySQL无法利用索引有序性直接返回排序结果，必须额外执行内存或磁盘排序；根本原因是索引结构与查询模式不匹配，如ORDER BY字段未命中最左前缀、被范围条件截断、方向不一致或未覆盖SELECT字段。
EXPLAIN里出现Using filesort说明什么
它不是报错，但明确告诉你：MySQL没法直接从索引里按顺序读出排序结果，必须先把符合条件的行捞出来，再额外做一次排序（内存或磁盘）。这个“额外”动作会吃CPU、占sort_buffer、可能触发磁盘临时文件，尤其配合LIMIT大偏移时，性能断崖下跌。
为什么加了索引还是触发Using filesort
常见错觉是“ORDER BY字段有索引就行”，实际关键在于：WHERE和ORDER BY是否能被**同一个索引连续覆盖**。以下情况会让索引对排序失效：
-
WHERE a > 1 ORDER BY b：a是范围条件，索引(a, b)中b已失去全局有序性 -
WHERE b = 1 ORDER BY a：b不是索引最左字段，无法定位起始位置 -
WHERE a = 1 ORDER BY c：跳过中间列b，索引(a, b, c)对c无效 -
ORDER BY a ASC, b DESC：MySQL 5.7及以前不支持混合方向，即使索引是(a, b)仍触发filesort -
SELECT *或返回未被索引覆盖的字段：回表后数据天然无序，排序动作仍会发生
怎么建组合索引才真正消除Using filesort
核心顺序必须是：等值过滤字段 → 范围过滤字段 → 排序字段，严格连续、不可跳跃。例如：
查询：SELECT id, name FROM users WHERE status = 1 AND age BETWEEN 18 AND 30 ORDER BY created_at DESC
正确索引：INDEX (status, age, created_at)
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
错误索引：INDEX (status, created_at, age)——age范围条件会破坏created_at的局部有序性
如果还要避免回表，且只查这三列，可扩展为：INDEX (status, age, created_at, id, name)（注意字段顺序）
容易被忽略的两个硬伤
一是JOIN场景下对非驱动表字段排序，比如JOIN orders o ON u.id = o.user_id ORDER BY o.created_at，即使o.created_at有索引，优化器大概率选users为驱动表，排序字段来自被驱动表，索引就废了；
二是GROUP BY在MySQL 8.0之前默认隐式排序，哪怕SQL没写ORDER BY，也会触发filesort——这种“看不见的排序”最容易漏掉。
