ORDER BY 字段未加索引或不满足最左前缀原则将触发 filesort；应优先复用过滤索引，按 WHERE+ORDER BY 顺序创建复合索引，并避免范围查询中断排序字段的有序性。
ORDER BY 字段没加索引，排序必然触发 filesort
MySQL 在执行 ORDER BY 时，如果排序字段不在可用索引的最左前缀中，或索引无法覆盖排序方向（如混合 ASC/DESC），就会退化为 filesort —— 这意味着数据要先取出再内存或磁盘排序，性能随结果集增长急剧下降。
常见错误现象：EXPLAIN 输出中 Extra 列出现 Using filesort；查询响应时间在 LIMIT 较大或数据量上升后明显变慢。
- 单字段排序：确保该字段单独建索引，或作为复合索引的最左列（例如
ORDER BY created_at→ 建INDEX(created_at)） - 多字段排序：必须严格匹配索引定义顺序和方向，例如
ORDER BY user_id ASC, score DESC需要索引INDEX(user_id, score)，且 MySQL 8.0+ 才支持混合方向索引（INDEX(user_id ASC, score DESC)） - 避免在排序字段上用函数或表达式，如
ORDER BY UPPER(name)会让索引失效
覆盖索引 + ORDER BY 能跳过回表和排序
当索引包含 SELECT 所有字段 + ORDER BY 字段时，MySQL 可直接按索引物理顺序扫描并返回结果，既免去回表，也省掉排序步骤 —— 这是排序查询优化的黄金组合。
使用场景：分页列表（如后台订单页）、排行榜（按分数倒序取前 100）、状态聚合页（按更新时间查最近操作）。
- 示例：查询
SELECT id, status, updated_at FROM orders WHERE status = 'paid' ORDER BY updated_at DESC LIMIT 20，最佳索引是INDEX(status, updated_at)（注意顺序！status 在前用于过滤，updated_at 在后支撑排序） - 若还需返回
user_id，索引应扩展为INDEX(status, updated_at, user_id)，否则会回表 - 注意：主键字段自动被聚簇索引覆盖，所以
id不必显式加入二级索引
WHERE 条件和 ORDER BY 共用索引时，最左前缀原则不能破
复合索引能否同时服务过滤和排序，取决于字段顺序是否满足最左前缀，且中间不能跳过字段。一旦 WHERE 用了范围条件（>, BETWEEN, LIKE 'abc%'），其右侧字段就无法用于排序。
典型翻车点：INDEX(a, b, c) 支持 WHERE a = 1 AND b > 10 ORDER BY c，但不支持 WHERE a > 1 ORDER BY b, c —— 因为 a 是范围查询，b 和 c 的有序性在索引中已中断。
- 验证方法：用
EXPLAIN FORMAT=TRADITIONAL查看key_len和Extra，确认实际用了索引哪几列 - 替代思路：把范围条件换成等值（如拆分时间段），或改用冗余索引（如额外建
INDEX(b, c)专用于该排序场景） - IN 查询比较特殊：MySQL 5.7+ 对
WHERE a IN (1,2,3) ORDER BY b可能利用INDEX(a,b)，但需实测key_len是否完整命中
小结果集排序靠索引意义不大，别盲目堆索引
当 ORDER BY 后加了 LIMIT 且数值很小（比如 LIMIT 10），即使没有对应索引，MySQL 也可能只排序几十行就结束 —— 此时建索引收益极低，反而增加写入开销和存储负担。
真正需要索引的，是那些「既要扫大量数据、又要稳定排序」的查询，比如导出报表、实时统计、滚动加载历史消息。
- 判断依据：看
EXPLAIN的rows值是否远大于LIMIT数值；若rows = 10000但LIMIT 10，说明排序前要筛出上万行，索引就关键 - 不要为每个
ORDER BY单独建索引，优先合并到已有过滤索引中；一个表索引总数建议控制在 5–8 个以内 - 时间字段排序最容易被忽略细节：
DATETIME和TIMESTAMP在时区处理、默认值行为上有差异，索引效果一致，但应用层逻辑错位会导致“明明有索引却不用”的假象
