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在时区处理、默认值行为上有差异，索引效果一致，但应用层逻辑错位会导致“明明有索引却不用”的假象
