ORDER BY 性能问题主因是未命中索引排序，需通过EXPLAIN检查Using filesort（MySQL）或Sort节点（PostgreSQL）；复合索引须按等值条件、范围条件、排序字段顺序构建，且方向严格匹配；大OFFSET应改用游标分页；ORDER BY NULL可禁用MySQL隐式排序。
ORDER BY 没走索引？先看执行计划
MySQL 或 PostgreSQL 中 ORDER BY 变慢，八成不是 SQL 写得差，而是没命中索引。别急着改查询，先用 EXPLAIN 看执行计划里有没有 Using filesort（MySQL）或 Sort 节点（PostgreSQL）。这个提示代表数据库在内存或磁盘上做了额外排序，性能瓶颈就在这儿。
- MySQL 中，
key列为空、Extra里出现Using filesort，说明没走索引排序 - PostgreSQL 中，
EXPLAIN输出里看到Sort且前面没Index Scan支撑排序字段，也意味着排序未下推到索引 - 复合索引顺序必须严格匹配
ORDER BY字段顺序和方向（ASC/DESC），比如ORDER BY a ASC, b DESC需要索引(a ASC, b DESC)，而不是(a, b)（MySQL 8.0+ 和 PG 支持混合方向，但老版本不认）
WHERE + ORDER BY 混用时，索引怎么建才有效
常见误区是给 WHERE 字段建一个索引、再给 ORDER BY 字段单独建一个——这样几乎没用。真正起效的是把两者合并进同一个复合索引，且顺序有讲究：先写等值过滤字段（= 或 IN），再写范围过滤字段（>, BETWEEN），最后才是排序字段。
- 例如查询
SELECT * FROM orders WHERE status = 'paid' AND created_at > '2024-01-01' ORDER BY amount DESC，最优索引是(status, created_at, amount DESC) -
status是等值条件，放最左；created_at是范围条件，放中间；amount是排序字段，放最后——这样索引能同时满足过滤和排序 - 如果把
amount放前面，索引对WHERE过滤就失效了；如果漏掉status，即使有(created_at, amount)，也大概率触发filesort
LIMIT 配合 ORDER BY 时，为什么加了索引还慢
加了正确索引、EXPLAIN 显示走了索引，但 LIMIT 10000, 20 依然卡顿？问题出在“跳过前 N 行”本身：数据库必须按索引顺序扫描并跳过 10000 条记录，才能取后面 20 条。跳得越远，成本越高。
- 避免大偏移量分页，改用游标分页（cursor-based pagination）：用上一页最后一条的
id或created_at做下次查询条件，例如WHERE id > 12345 ORDER BY id LIMIT 20 - 如果必须用
OFFSET，确保排序字段有高选择性（比如id），低选择性字段（如status）即使有索引，跳过大量重复值仍很慢 - MySQL 8.0+ 的
SKIP语法暂未解决此问题，别被名字误导；PostgreSQL 的OFFSET同样是线性扫描跳过
ORDER BY NULL 和强制不排序的适用场景
某些聚合或去重查询根本不需要排序结果，但 MySQL 默认会对 GROUP BY 或 DISTINCT 隐式加 ORDER BY，导致多余排序开销。这时加 ORDER BY NULL 是明确告诉优化器：别排了。
- 仅适用于 MySQL；PostgreSQL 不支持该语法，需用
GROUP BY ... ORDER BY (SELECT NULL)或直接依赖 planner 行为（通常不自动排序） - 只在确认业务不要求顺序时使用，比如后台导出统计报表、缓存预热数据等场景
- 注意：
ORDER BY NULL不会阻止索引使用，但它绕过了排序阶段——如果原本就有排序需求，加它反而导致结果乱序
真正难的不是建索引，而是判断哪些字段该进复合索引、哪些不该，以及什么时候该放弃 OFFSET。线上慢查里，多数 ORDER BY 性能问题都卡在“以为索引建对了”，其实顺序或覆盖度差了一步。
