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——这是最直接的信号。索引不是加了就有效，排序字段的位置、方向、覆盖度，缺一不可。
