order by 走索引需满足最左前缀匹配、无函数表达式、且优化器认为索引排序更优；例如联合索引(a,b,c)支持order by a、a,b、a,b,c，但不支持b或c单独排序。
ORDER BY 字段没走索引？先看是否满足最左前缀匹配
MySQL 的 ORDER BY 能用上索引的前提，是排序字段构成索引的**最左连续前缀**。比如有联合索引 INDEX idx_a_b_c (a, b, c)，那么 ORDER BY a、ORDER BY a, b、ORDER BY a, b, c 可以走索引；但 ORDER BY b 或 ORDER BY c 就不行，哪怕字段都在索引里。
常见错误现象：EXPLAIN 显示 type=ALL 或 Extra: Using filesort，说明排序没走索引。
- 如果查询带
WHERE条件，要确保WHERE和ORDER BY共同满足最左前缀——例如WHERE a = 1 ORDER BY b, c可用idx_a_b_c；但WHERE b = 1 ORDER BY a就不行 - 升序/降序混合时（如
ORDER BY a ASC, b DESC），MySQL 8.0+ 才支持在联合索引中为不同字段定义方向；5.7 及以前只要有一个DESC，整个ORDER BY就无法用索引排序 - 避免在排序字段上用函数或表达式：
ORDER BY UPPER(name)或ORDER BY created_at + INTERVAL 1 DAY会直接失效索引
WHERE + ORDER BY 混合场景下，索引字段顺序怎么排？
联合索引的字段顺序不是按“查询频率”排，而是按「过滤强度高 + 排序需求稳定」来权衡。高选择性字段（如用户 ID、订单号）适合放前面，但若排序字段固定且必须走索引，它就得挤进最左位置。
使用场景举例：分页查「某类订单按创建时间倒序」，WHERE status = 'paid' ORDER BY created_at DESC。
- 建索引优先考虑
INDEX idx_status_created (status, created_at)，而非(created_at, status)——因为status是等值条件，放前面才能让created_at成为排序的连续后缀 - 如果
status区分度极低（比如只有 2–3 个值），而查询又常按created_at大范围扫描，那这个索引可能反而拖慢写入、浪费空间；此时需评估是否值得为排序单独建索引 - 不要为了覆盖所有排序组合建一堆索引，比如同时建
(a,b)、(b,a)、(a,b,c)——维护成本和写性能损耗会明显上升
SELECT * 导致排序索引失效？和回表有关
即使 ORDER BY 本身能走索引，如果 SELECT 列太多，MySQL 可能放弃索引排序，转而用文件排序（Using filesort），尤其当索引不包含所有需要返回的字段时。
本质是优化器判断：走索引排序 + 回表取数据，不如全表扫描 + 内存排序快。
- 用
EXPLAIN FORMAT=TREE（8.0+）或观察Extra字段是否出现Using index for order by，这是真正“只靠索引完成排序”的信号 - 想触发该优化，索引必须是“覆盖索引”：即
SELECT的所有列 +WHERE条件列 +ORDER BY列，全部包含在同一个索引中 - 示例：查询
SELECT id, name FROM users WHERE dept_id = 10 ORDER BY create_time DESC，可建INDEX idx_dept_ct_id_name (dept_id, create_time, id, name)
ORDER BY RAND() 怎么办？别硬刚索引
ORDER BY RAND() 天然无法走任何索引，因为它是逐行计算随机值。这不是索引策略问题，而是语义决定的——MySQL 必须给每行算一次 RAND()，再排序，没有捷径。
常见错误现象：小表看不出问题，一旦表过万行，查询直接卡死。
- 替代方案不是调索引，而是换思路：比如用主键范围随机抽样（
SELECT * FROM t WHERE id BETWEEN FLOOR(RAND() * (SELECT MAX(id) FROM t)) AND ... LIMIT 1），或提前生成随机 ID 列表 - 如果业务真需要“每次随机且均匀”，考虑在应用层缓存全量 ID 数组，用程序随机选，再查库——比数据库硬算
RAND()稳定得多 - 千万别在大表上加索引试图优化
RAND()，只会白费力气
排序字段是否走索引，核心就三点：字段是否在索引最左连续位置、是否被函数/表达式污染、以及 SELECT 列是否让优化器觉得“走索引不划算”。很多 case 看似调序就能解决，其实背后是过滤条件选择性、数据分布、甚至 MySQL 版本对排序方向的支持程度在起作用——得一个个实测，不能只看理论。
