ORDER BY 不走索引的明确信号是 EXPLAIN 出现 Using filesort；主因包括缺索引、类型不匹配、联合索引未覆盖查询字段或排序方向不一致，优化需按等值条件→排序字段顺序建联合索引，并避免函数、RAND()、大偏移分页。
ORDER BY 没走索引？先看执行计划里有没有 Using filesort
MySQL 里 ORDER BY 不走索引，最直接的信号就是 EXPLAIN 结果中出现 Using filesort。这不是警告，是确诊——说明 MySQL 正在内存或磁盘上做二次排序，性能已经掉坑里了。
常见触发场景：ORDER BY 字段没索引、字段类型和索引类型不一致（比如索引是 VARCHAR(255)，ORDER BY 却用了 VARCHAR(100) 隐式截断）、或者 WHERE 条件和 ORDER BY 字段无法共用同一个联合索引。
- 检查索引是否覆盖查询：
SELECT的字段 +WHERE条件字段 +ORDER BY字段，最好能落在同一个联合索引里，顺序按「等值条件 → 最左前缀匹配 → 排序字段」排 - 避免在
ORDER BY字段上用函数，比如ORDER BY UPPER(name)，会直接废掉索引 - 如果必须排序非索引字段，考虑加覆盖索引，而不是靠
filesort硬扛
多字段 ORDER BY 时，ASC/DESC 混用导致索引失效
MySQL 8.0 之前，联合索引对混合排序方向支持极差。比如建了 INDEX (a, b)，ORDER BY a ASC, b DESC 就不会走索引——因为 B+ 树天然只支持单向遍历。
8.0+ 虽然支持 INDEX (a ASC, b DESC) 这种显式定义，但实际生效有硬限制：所有等值条件字段后的第一个排序字段，必须和索引定义方向严格一致；一旦中间有跳过或方向冲突，后续字段全作废。
- 优先统一排序方向：能写成
ORDER BY a ASC, b ASC就别写b DESC，除非业务强依赖 - 真要混合排序，索引必须显式声明对应方向，且不能有“断层”：比如
INDEX (a ASC, b DESC, c ASC)，那ORDER BY a ASC, b DESC可用，但ORDER BY a ASC, c ASC不可用 - 注意 NULL 值处理：
ORDER BY col DESC会把NULL排最前，而索引默认把NULL当最小值，方向可能错位
LIMIT 配合 ORDER BY 时，偏移量大导致慢查
ORDER BY created_at DESC LIMIT 10000, 20 这类分页，在 MySQL 里本质是“先排序前 10020 行，再丢掉前 10000 行”。偏移量越大，扫描和排序成本越高，和数据量呈线性关系。
这不是 SQL 写得不对，是物理执行逻辑决定的——MySQL 没法跳过前 N 行直接取第 N+1 行，除非借助有序索引+游标。
- 用游标替代 offset：记录上一页最后一条的
created_at和id，下一页查WHERE created_at - 避免
SELECT *：只查必要字段，减少排序时的行大小，降低内存压力 - 如果业务允许，把排序字段换成带唯一性、高区分度的列（如自增
id），比时间戳更稳定、更容易利用索引定位
ORDER BY RAND() 是性能黑洞，别在线上用
ORDER BY RAND() LIMIT 1 看似简单，实则灾难：MySQL 必须给表里每一行都算一次随机数，再全排序，哪怕只要 1 行。10 万行表，就要算 10 万次 RAND()，再排序 10 万行。
它不走索引、不缓存、不可预测，而且随着数据增长，耗时指数级上升。
- 用主键范围随机：先
SELECT MIN(id), MAX(id) FROM table，再应用层生成随机id，查WHERE id >= ? LIMIT 1（注意空洞问题，可试 2–3 次） - 如果必须均匀抽样，考虑提前把随机顺序固化到辅助表，用定时任务打散更新
- 绝对不要在
WHERE条件还没过滤完就ORDER BY RAND()，那是在给无效数据陪跑
排序优化不是调个参数的事，是索引结构、查询写法、数据分布三者咬合的结果。最容易被忽略的，其实是 WHERE 条件字段和 ORDER BY 字段在联合索引里的相对位置——差一个字段顺序，可能就从毫秒变秒级。
