explain中出现using filesort说明mysql无法利用索引有序性直接返回排序结果，必须额外执行内存或磁盘排序，导致cpu和io开销陡增；根本原因是索引结构与查询模式不匹配，如order by字段未命中最左前缀、被范围条件截断、方向不一致或未覆盖select字段。
EXPLAIN里出现Using filesort说明什么
它不是“用了磁盘排序”，而是MySQL没法靠索引顺序直接返回结果，必须额外做一次排序——无论内存还是临时表，都意味着IO和CPU开销陡增。尤其配合LIMIT偏移时，性能会断崖下跌。你看到Using filesort，本质上就是索引没对上查询模式。
联合索引字段顺序怎么排才真正生效
顺序必须严格匹配查询的执行逻辑：先WHERE等值条件字段，再ORDER BY字段，中间不能跳、不能反、不能被范围条件截断。
-
WHERE status = 'active' ORDER BY created_at DESC→ 索引必须是INDEX (status, created_at)，不能是(created_at, status)或只建(created_at) -
WHERE user_id = 100 AND age > 25 ORDER BY score→age是范围条件，score虽在索引中紧随其后（如(user_id, age, score)），仍可被用于排序；但若写成WHERE user_id > 100 ORDER BY age，则age已不保证有序，索引失效 - 多个排序字段方向要一致：MySQL 8.0+支持
INDEX (a ASC, b DESC)对应ORDER BY a ASC, b DESC；5.7及以前只能全ASC或全DESC，否则部分字段无法利用
要不要把SELECT字段加进索引里
这不是锦上添花，而是关键取舍：加进去是为了构成覆盖索引，避免回表。但优先级永远是——先让排序走索引，再考虑覆盖。
- 查
id, name, created_at，WHERE+ORDER BY用到status, created_at→ 至少建INDEX (status, created_at, id, name)，字段顺序按SELECT列表补全 - 如果后续加了
SELECT *，别盲目把所有字段塞进索引——空间膨胀快，写入变慢，收益反而下降 - 注意：
TEXT、BLOB这类大字段不能建索引，覆盖索引里得排除它们
建了索引还是出现Using filesort？先查这三件事
索引存在 ≠ 被选用。优化器可能因为统计信息不准、成本误判或隐式类型转换而弃用你的索引。
- 执行
ANALYZE TABLE table_name更新统计信息，尤其在大批量导入后 - 检查字段类型是否严格匹配：
WHERE phone = 13800138000（数字） vsphone VARCHAR(20)→ 隐式转换导致索引失效 - 用
FORCE INDEX临时验证：如果加了USE INDEX(idx_name)后Using filesort消失，说明优化器主动绕开了它，得查执行计划里的rows预估是否严重偏差
最常被忽略的点：索引能消除Using filesort，但未必能同时消除Using temporary——后者往往由GROUP BY或去重引起，得单独处理。
