能，MySQL仅在联合索引列顺序严格匹配WHERE等值条件+ORDER BY字段组合且不破坏最左前缀原则时才可跳过filesort；等值条件须连续前置，ORDER BY字段须紧随其后且方向一致，范围条件会截断后续索引能力，覆盖索引需包含查询字段以避免回表。
能，但前提是联合索引的列顺序严格匹配查询中WHERE等值条件 + ORDER BY字段的组合，并且不破坏最左前缀原则。
联合索引必须按 WHERE 等值条件 + ORDER BY 字段顺序创建
MySQL 只有在索引列顺序与查询逻辑完全对齐时，才能跳过 filesort。比如查询是 WHERE user_id = 12345 AND status = 1 ORDER BY created_at DESC，那么索引必须是 (user_id, status, created_at)，而不是 (user_id, created_at, status) —— 后者会让 status 失去等值过滤能力，created_at 也无法被用于排序。
- 等值条件（
=、IN）可以放在联合索引前段，顺序可交换，但必须连续 - ORDER BY 字段必须紧跟在所有等值条件之后，且方向一致（ASC/DESC 要和索引定义一致）
- 范围条件（
>、BETWEEN）会截断后续字段的索引能力，不能放在 ORDER BY 字段前面
避免 SELECT * 导致回表，优先用覆盖索引
即使联合索引能消除 filesort，如果查询字段不在索引里，MySQL 还得回主键索引查完整行，IO 开销大。比如 SELECT id, title FROM orders WHERE user_id = 12345 ORDER BY created_at，只建 (user_id, created_at) 是不够的——它不包含 id 和 title，仍要回表。
- 把常用查询字段加到联合索引末尾，构成覆盖索引：
(user_id, created_at, id, title) - 注意索引宽度：加太多字段会让索引变大，影响写入性能和内存占用，只加真正需要的字段
- 用
EXPLAIN检查Extra是否出现Using index，这是覆盖索引生效的标志
当 WHERE 条件含可选参数时，索引容易失效
比如动态查询中 orders_status 是可选的：WHERE user_id = ? AND (orders_status = ? OR orders_status IS NULL) ORDER BY sort_by。这种写法会让 (user_id, orders_status, sort_by) 索引大概率无法命中，因为优化器很难判断是否能跳过 orders_status。
- 拆成多个固定路径的查询，分别走不同索引，比如
(user_id, sort_by)和(user_id, orders_status, sort_by) - 改用游标分页替代
LIMIT offset, size，避免OFFSET引发的扫描放大 - 确认
EXPLAIN中的key字段是否真的用了你建的索引，别只看type是ref就以为没问题
最容易被忽略的是：ORDER BY 字段的排序方向必须和索引定义完全一致。建了 INDEX idx (a, b ASC)，却执行 ORDER BY a, b DESC，MySQL 依然会触发 Using filesort。哪怕只差一个 DESC，索引就废了一半。
