using filesort表示mysql无法利用索引有序性完成排序，必须额外内存或磁盘排序；根本原因是索引结构与查询模式不匹配，如未满足最左前缀、范围条件截断、升降序不一致、函数表达式或非驱动表排序等。
出现 Using filesort 就代表 MySQL 没法靠索引直接输出有序结果，必须额外排序——这不是“可能慢”，是排序逻辑已脱离索引结构，哪怕只返回 10 行，它也得先把所有匹配行捞出来再排。
为什么加了索引还是触发 Using filesort
索引存在 ≠ 排序可用。关键在于：MySQL 必须能用**同一个索引**一次性完成 WHERE 过滤 + ORDER BY 排序，且字段顺序、方向、条件类型严丝合缝。
-
WHERE created_at > '2023-01-01' ORDER BY updated_at：范围条件截断索引，created_at后的字段无法复用有序性 -
WHERE status = 1 ORDER BY id，但索引是(id, status)：最左前缀不匹配，status不是首列，索引根本没法定位起始位置 -
ORDER BY UPPER(name)或ORDER BY a + b：索引存的是原始值，函数/表达式结果无法对齐 -
ORDER BY user_id ASC, pay_time DESC，但 MySQL 5.7 及以前建的索引是(user_id, pay_time)（全 ASC）：混合方向不被支持，优化器直接忽略 -
SELECT *即使ORDER BY id走主键，也会因回表打乱物理顺序，导致内存重排
EXPLAIN 里 key 有值但仍有 Using filesort 怎么办
这说明索引被用于查找（key 非 NULL），但没用于排序——问题出在「查」和「排」没共用同一段索引结构。
- 检查
WHERE条件是否用了等值匹配（=、IN）：只有等值字段才能作为索引前缀稳定锚定；范围条件（>、BETWEEN）之后的字段，排序能力即告终止 - 确认
ORDER BY字段是否紧接在等值字段之后，且未跳过中间列：索引(a, b, c)支持ORDER BY a, b或a, b, c，但不支持a, c - 看 MySQL 版本：8.0.12+ 才真正支持
INDEX (a ASC, b DESC)，5.7 建了也白建，会按全 ASC 存储 - 避免
SELECT *：如果只查id, name, created_at，就建覆盖索引(status, created_at, id, name)，别让回表破坏顺序
多表 JOIN 时 ORDER BY 引用被驱动表字段
MySQL 默认只对驱动表（FROM 后第一张表）的 ORDER BY 字段尝试走索引排序。一旦排序字段来自被驱动表，比如 JOIN orders o ON u.id = o.user_id ORDER BY o.total DESC，即使 orders.total 有索引，也基本必出 Using filesort。
- 给被驱动表单独建索引无效——优化器不会跨表利用索引做排序
- 可行解法一：延迟关联，先
SELECT u.id FROM users u ... ORDER BY o.total LIMIT 20套子查询拿到主键，再用IN回表补字段 - 可行解法二：把被驱动表排序字段“拉”进驱动表索引，例如在
users上建(status, o_total)，前提是o_total能通过 JOIN 条件可靠映射且值域可控 - 注意：MySQL 8.0 之前
GROUP BY隐式排序也会触发Using filesort，即使 SQL 里没写ORDER BY，这点极易被忽略
真正难的不是建索引，是让索引字段顺序、WHERE 条件、ORDER BY 字段、升降序声明四者咬死对齐——差一个等号、少一个 DESC、多一个函数，Using filesort 就照出不误。
