最有效方式是创建最左匹配的联合索引，确保where等值字段在前、order by字段紧随其后且顺序方向一致，使mysql直接按b+树物理顺序读取，跳过排序。
联合索引如何让ORDER BY直接走索引顺序
因为B+树索引天然有序，只要查询的 ORDER BY 字段能被索引的最左前缀连续覆盖，MySQL就能按索引物理存储顺序逐条读取，跳过额外排序步骤。这不是“加速排序”，而是根本不用排序。
关键前提是：WHERE等值条件字段必须排在ORDER BY字段之前，且中间不能被范围条件（如 >、BETWEEN、IN）截断——否则后续字段在索引中不再保证全局有序。
-
WHERE status = 'active' ORDER BY created_at DESC→ 索引(status, created_at)有效 -
WHERE user_id = 100 AND age > 25 ORDER BY score→ 索引(user_id, age, score)仍可排序（age是范围，但score紧随其后，在该user_id下仍局部有序） -
WHERE user_id > 100 ORDER BY age→ 即使有(user_id, age)索引，age也不再有序，必然Using filesort
为什么ASC/DESC混用常导致filesort失效
MySQL 5.7及以前版本只支持全ASC或全DESC的索引扫描；8.0.12+虽支持反向索引扫描，但前提是索引定义中明确声明了方向，比如 INDEX (a ASC, b DESC) 才能匹配 ORDER BY a ASC, b DESC。若索引是 (a, b)（默认ASC），而查询写成 ORDER BY a ASC, b DESC，优化器无法复用索引顺序，只能回退到filesort。
注意：即使你建了 (a ASC, b DESC)，如果WHERE里用了 a IN (...)，它对排序来说等效于范围条件，b字段仍可能无法利用有序性。
多表JOIN时ORDER BY被驱动表字段为何总触发filesort
MySQL只对驱动表（FROM后的第一张表）的 ORDER BY 字段尝试索引排序；一旦排序字段来自被驱动表（如 JOIN orders o ON u.id = o.user_id ORDER BY o.total），即使 orders 表上有 (total) 索引，也完全无效——索引不跨表参与排序路径。
常见误判点：
- 以为给被驱动表加索引就能解决 → 实际无用
- 在驱动表索引里硬塞被驱动表字段（如
users(status, id, total)）→ total不是users的列，建不起来 - 正确解法是延迟关联：先
SELECT u.id FROM users u ... ORDER BY o.total LIMIT 20（子查询只取主键），再用主键回表补全字段
覆盖索引和filesort的关系容易被高估
加SELECT字段进联合索引（构成覆盖索引）是为了避免回表，不是为了消灭filesort。优先级永远是：先确保 ORDER BY 字段能走索引顺序，再考虑是否覆盖。
例如：SELECT id, name FROM t WHERE status = 'draft' ORDER BY created_at，最优索引是 (status, created_at, id, name)；但如果后续改成 SELECT *，别把所有字段都塞进去——大字段（如 TEXT）不能建索引，且索引体积膨胀会拖慢INSERT/UPDATE，反而得不偿失。
最常被忽略的一点：Using index 出现在EXPLAIN的Extra里，只代表取数据走了覆盖索引，不代表排序也走了索引——仍可能同时出现 Using filesort。
