order by 能否走索引取决于where与order by字段是否构成索引最左前缀且顺序匹配；需避免函数、NULL处理不当、非覆盖索引及order by rand()等陷阱。
ORDER BY 走不了索引？先看 WHERE 和 ORDER BY 字段顺序是否匹配
mysql 和 postgresql 的 B-tree 索引对 ORDER BY 生效的前提，是排序字段构成索引的最左前缀，且未被 WHERE 条件“打断”。比如建了 INDEX (a, b, c)，WHERE a = 1 ORDER BY b, c 能用上；但 WHERE b = 1 ORDER BY c 就完全用不上——因为 b 不是索引首列。
常见错误现象：EXPLAIN 显示 type=ALL 或 Extra: using filesort，明明有索引却没走。
- 如果查询带
WHERE，优先把过滤性最强的字段放索引最左，再接ORDER BY字段（保持顺序一致） - 避免在
ORDER BY字段上用函数或表达式，如ORDER BY UPPER(name)会直接失效 - PostgreSQL 对
DESC/ASC敏感：索引定义是(a ASC, b DESC)，那ORDER BY a ASC, b DESC才能命中；反过来就失效
多字段排序时 NULL 值让索引失效？别硬扛，显式控制排序行为
默认情况下，ORDER BY x 把 NULL 当作最小值（MySQL）或最大值（PostgreSQL），而索引本身不存储 NULL 的逻辑位置，导致优化器放弃使用索引。尤其当字段允许 NULL 且数据中实际存在大量空值时，这个问题更隐蔽。
使用场景：用户列表按 last_login_time 倒序展示，该字段可为空，结果发现分页变慢、EXPLAIN 显示 Using filesort。
- 显式声明
NULLS FIRST或NULLS LAST（PostgreSQL 支持，MySQL 8.0.22+ 也支持）并确保索引定义与之匹配 - 更稳妥的做法：用
COALESCE(last_login_time, '1970-01-01')统一补值，但要注意补值不能破坏业务语义和范围查询逻辑 - 如果只是想把非空值排前面，
ORDER BY last_login_time IS NULL, last_login_time DESC是兼容性最好的写法，且能走索引（前提是last_login_time在索引中）
覆盖索引 + ORDER BY：少一次回表，性能可能翻倍
即使 ORDER BY 能走索引，如果 select * 或查询字段不在索引里，数据库仍要回表查完整行——这对大偏移量分页（如 LIMIT 10000, 20）尤其致命。覆盖索引能让排序和取值一步完成。
参数差异：索引字段顺序必须同时满足过滤、排序、查询三重需求。不是“越多越好”，而是“够用且顺序合理”。
- 例如查
SELECT id, name, status FROM users WHERE status = 'active' ORDER BY created_at DESC，最优索引是INDEX (status, created_at DESC, id, name) - 注意
id和name放在排序字段后，是为了覆盖查询；但如果只查id，那INDEX (status, created_at DESC, id)就足够 - 不要把
TEXT或大字段加进索引——它们不参与排序加速，反而拖慢写入和索引体积
ORDER BY RAND() 是性能黑洞，换种思路生成随机行
ORDER BY RAND() 看似简单，实则会让优化器放弃所有索引，对全表每行计算随机数再排序，时间复杂度 O(n log n)。哪怕只有几万行，响应也可能秒级起步。
真实痛点：后台需要“随机推荐 5 条商品”，开发随手写了 SELECT * FROM products ORDER BY RAND() LIMIT 5，上线后监控报警。
- 小表（SELECT id FROM products 拿全部 ID，再内存 shuffle 取 5 个，最后
WHERE id IN (...) - 大表：用
WHERE id >= FLOOR(RAND() * (SELECT MAX(id) FROM products)) LIMIT 1多次执行（可能需去重），比全表RAND()快一个数量级 - 如果业务允许近似随机，给表加个
random_score Float字段，定期用UPDATE products SET random_score = RAND()刷新，查询时ORDER BY random_score LIMIT 5就能走索引
复杂点往往藏在“看起来无害”的写法里，比如 ORDER BY 后面跟了个函数，或者以为加了索引就万事大吉——其实得看它是不是真被用了，以及用了多少。