ORDER BY 能用索引吗？取决于字段和索引结构
能，但不是所有
ORDER BY都走索引。MySQL 只有在满足「索引最左前缀 + 排序方向一致 + 无函数/表达式干扰」时，才可能利用索引避免文件排序（
Using filesort）。比如表有联合索引
INDEX (a, b)，那么
ORDER BY a, b或
ORDER BY a可走索引；但
ORDER BY b或
ORDER BY a DESC, b ASC（混合方向）通常不行。
如何判断 ORDER BY 是否用了索引？看执行计划
用
EXPLAIN查看
Extra列： 出现
Using filesort→ 没走索引排序，MySQL 在内存或磁盘做二次排序 没有
Using filesort，且
key列显示用了某个索引 → 排序由索引天然有序性完成 注意：即使
type是
index或
range，也不代表排序走了索引——关键还是看
Extra
常见失效场景和绕过方法
以下情况会让
ORDER BY强制退化为 filesort：
SELECT *+
ORDER BY非覆盖索引字段 → 回表后无法保持顺序，必须再排序
WHERE条件用了非最左前缀字段，比如索引是
(a, b, c)，却写
WHERE b = 1 ORDER BY c
ORDER BY RAND()、
ORDER BY UPPER(name)等带函数的表达式 → 索引值不匹配原始列内容 多表 JOIN 后
ORDER BY字段来自被驱动表 → 优化器常放弃索引排序
绕过思路：优先让
SELECT字段和
ORDER BY字段都落在同一覆盖索引中；必要时拆分查询，或用主键分页替代
LIMIT offset, size。
ORDER BY + LIMIT 的索引优化技巧
这是高并发分页的性能关键点。如果
ORDER BY id LIMIT 10走了索引，但
ORDER BY id LIMIT 10000, 10依然要扫描前 10000 行。 用游标分页：
WHERE id > ? ORDER BY id LIMIT 10，配合上一页末尾
id值 避免
SELECT *：只查必需字段，减少回表和排序开销 对高频排序字段单独建索引，哪怕冗余，比如
CREATE INDEX idx_sort_status_ctime ON t (status, ctime DESC)
真正卡顿的往往不是排序本身，而是排序前的数据集太大——先用
WHERE尽量缩小结果集，再考虑排序是否能走索引。
