ORDER BY 未走索引主因是字段未被索引覆盖，EXPLAIN 出现 Using filesort 即表明；复合索引须严格匹配排序字段顺序与方向，WHERE 与 ORDER BY 共用索引可提升性能。
ORDER BY 没走索引？先看执行计划
绝大多数慢排序，根本不是写法问题，而是 ORDER BY 字段没被索引覆盖。MySQL 和 PostgreSQL 都会优先尝试用索引来避免文件排序（Using filesort），但这个“尝试”很娇气。
实操建议：
- 用
EXPLAIN查看查询的Extra列：出现Using filesort就说明排序没走索引 - 复合索引顺序必须严格匹配
ORDER BY的字段顺序和方向（ASC/DESC），例如ORDER BY status ASC, created_at DESC需要索引(status, created_at)且第二个字段声明为DESC（MySQL 8.0+ 支持，老版本只认全ASC） - 如果
WHERE条件用了status = ?，再加ORDER BY created_at，那索引(status, created_at)就能同时加速过滤和排序
分页深翻（LIMIT offset, size）卡顿怎么破
当 offset 超过几万行，数据库仍得从头扫出前 N 行再丢弃——这不是效率问题，是算法缺陷。
实操建议：
- 用游标分页替代偏移分页：记录上一页最后一条的
id或created_at，下一页查WHERE id > ? ORDER BY id LIMIT 20 - 避免
ORDER BY RAND()+LIMIT，它会强制扫描全表；真要随机取几条，先用SELECT id FROM table ORDER BY RAND() LIMIT 10拿 ID，再JOIN或IN查详情 - PostgreSQL 用户可考虑
TABLESAMPLE做近似随机采样，不保证均匀但极快
多字段排序时 NULL 值搅局
默认情况下，NULL 在升序中排最前、降序中排最后，常导致结果和预期错位，尤其在分页或前端渲染时突然“跳行”。
实操建议：
- 显式控制
NULL位置：MySQL 用ORDER BY field_name IS NULL, field_name ASC；PostgreSQL 用ORDER BY field_name NULLS FIRST或NULLS LAST - 如果业务逻辑要求
NULL视为最小值（如未填写时间按最早处理），别依赖默认行为，统一补COALESCE(created_at, '1970-01-01')再排序 - 注意
NULL处理会影响索引使用：带IS NULL条件的排序，索引可能失效，优先改数据模型（比如用0或极小时间占位）
ORDER BY + JOIN 导致排序失效
连接多个表后，数据库可能放弃使用索引排序，尤其当 ORDER BY 字段来自被驱动表（非主表）、或连接条件未覆盖排序字段时。
实操建议：
- 确保
ORDER BY字段所属的表是驱动表（STRAIGHT_JOIN可强制，但慎用）；更稳妥的是把排序字段所在表作为主表（FROM orders而非FROM users） - 避免在
JOIN后对计算字段排序，例如ORDER BY CONCAT(u.first_name, ' ', u.last_name)—— 索引完全无效，提前在应用层拼或建生成列索引 - MySQL 中若
ORDER BY字段带函数（如UPPER(name)），即使有索引也用不上，除非建函数索引（MySQL 8.0+）
真正卡住性能的往往不是语法本身，而是索引能否覆盖「过滤 + 排序 + 返回字段」这三段链条。少一个环节，就多一次临时表或文件排序——而这两者在数据量上 10 倍增长时，代价可能是百倍。
