Using filesort表示排序未使用索引，MySQL必然进行内存或磁盘硬排序；需确保ORDER BY字段有索引或为复合索引最左前缀，且WHERE与ORDER BY字段组合成连续最左前缀，避免低区分度字段打头，并用游标分页替代深偏移LIMIT。
Explain里看到Using filesort就说明排序没走索引
只要执行计划extra列出现using filesort，基本等于mysql在内存或磁盘里硬排序——没用上order by字段的索引。这不是“可能慢”，而是“一定绕过索引排序能力”。常见诱因是order by字段没索引、索引顺序不匹配、或where条件让优化器放弃使用排序索引。
ORDER BY字段必须单独建索引或作为复合索引最左前缀
复合索引INDEX(a, b, c)能加速ORDER BY a、ORDER BY a,b、ORDER BY a,b,c，但对ORDER BY b或ORDER BY c完全无效。如果查询同时有WHERE和ORDER BY，优先保证WHERE条件字段+ORDER BY字段组合成连续最左前缀：
-
WHERE status = 'active' ORDER BY created_at→ 建INDEX(status, created_at) -
WHERE user_id = 123 ORDER BY score DESC→ 建INDEX(user_id, score)（DESC在8.0+才真正生效，5.7及以前建法一样） - 避免
WHERE deleted = 0 ORDER BY id这种低区分度字段打头的索引——优化器大概率跳过
分页深翻时ORDER BY + LIMIT容易失效
SELECT * FROM logs ORDER BY id DESC LIMIT 10000, 20这类语句，即使id有索引，MySQL仍要先扫完前10000行才能取后20行，rows值会暴增。更糟的是，如果WHERE过滤后结果集小但ORDER BY字段无索引，Using filesort会直接拖垮性能。
- 改用游标分页：
WHERE id （?为上一页最后id） - 强制走索引：
FORCE INDEX (idx_order_field)，但仅当确认该索引比全表扫描快时才用 - 别信
SELECT *+ORDER BY：返回字段越多，排序缓冲区压力越大，Using filesort越容易溢出到磁盘
字符集/排序规则不一致会废掉ORDER BY索引
如果ORDER BY name字段的COLLATE和查询连接中其他字段不一致（比如JOIN另一张表的name字段是utf8mb4_0900_as_cs，而本表是utf8mb4_unicode_ci），MySQL无法安全比较，会退回到Using filesort。Navicat结构比对里标红的COLLATE差异，背后可能就是这个隐患。
- 查实际生效规则：
SHOW CREATE TABLE your_table，看CREATE TABLE语句里字段是否显式声明COLLATE - 统一COLLATE不是为了“好看”，而是避免隐式转换导致索引失效
- 特别注意JOIN条件字段、WHERE条件字段、ORDER BY字段三者COLLATE必须一致
排序性能问题最隐蔽的地方在于：Using filesort本身不报错，SQL照样返回结果，只是慢得不讲道理。等你发现时，往往已经在线上跑了很久。
