ORDER BY字段必须位于索引最左前缀且顺序、方向严格匹配，否则触发filesort；应使用覆盖索引避免回表与排序开销；ORDER BY RAND()不可用索引，需改用主键范围随机查询等替代方案。
ORDER BY 字段必须落在索引最左前缀上
MySQL 只有在 ORDER BY 的字段顺序和索引定义顺序完全一致（且方向一致，如都是 ASC 或都是 DESC），并且没有跳过中间列时，才能用上索引来避免文件排序（Using filesort）。比如表上有复合索引 INDEX idx_user_status_created (status, created_at, user_id)，那么以下查询能走索引排序：
SELECT * FROM orders WHERE status = 'paid' ORDER BY created_at, user_id;
但这些不行：
-
ORDER BY user_id（跳过了created_at） -
ORDER BY created_at DESC, user_id ASC（混合排序方向，MySQL 8.0 之前不支持） -
ORDER BY status, user_id（status是等值条件，但user_id跳过了created_at）
避免 SELECT * + ORDER BY 引发的回表与排序开销
当 ORDER BY 使用索引，但 SELECT 列不在该索引中时，MySQL 仍需回表取数据，且若结果集较大，可能触发临时表或磁盘排序。更糟的是，如果优化器判断「走索引排序 + 回表」比「全表扫描 + 文件排序」还慢，它会直接放弃索引。
解决思路是让覆盖索引生效：
- 把常用查询字段加入索引末尾，例如：原索引
idx_status_created扩展为idx_status_created_uid_amount (status, created_at, user_id, amount) - 配合
SELECT user_id, amount这类只查索引列的语句，就能彻底避免回表和Using filesort - 注意：索引越宽，写入开销越大，别无脑堆字段
ORDER BY RAND() 无法用索引，必须换方案
ORDER BY RAND() LIMIT 1 是典型反模式——它强制 MySQL 对全表逐行计算随机数并排序，哪怕只有 1 行结果，也会触发全表扫描和临时内存/磁盘排序。线上大表执行一次就可能拖垮查询线程。
替代做法（按场景选）：
- 已知主键范围：先
SELECT FLOOR(RAND() * (max_id - min_id)) + min_id算出随机 ID，再SELECT ... WHERE id >= ? ORDER BY id LIMIT 1 - 数据量不大（WHERE id IN (...)
- 需要真正均匀抽样：用
SELECT * FROM t TABLESAMPLE SYSTEM (1)（MySQL 8.0.23+ 支持，但非精确比例）
多字段排序时 DESC/ASC 混用的兼容性陷阱
MySQL 8.0 之前，复合索引中只要有一个字段声明为 DESC，整个索引就无法用于 ORDER BY 排序（即使查询里全是 ASC）。8.0+ 支持降序索引，但要注意：
- 建索引时要显式写明方向：
CREATE INDEX idx_a_b_desc ON t(a ASC, b DESC) - 查询中
ORDER BY a ASC, b DESC才能命中；反过来写ORDER BY a DESC, b ASC就不走索引 - 如果业务同时需要多种排序组合，可能需要多个方向不同的索引，空间成本上升
上线前务必用 EXPLAIN 看 Extra 列是否还有 Using filesort——这是最直接的信号。索引不是加了就有效，排序字段的位置、方向、覆盖度，缺一不可。
