SQL ORDER BY 排序性能优化实践

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 性能问题都卡在“以为索引建对了”，其实顺序或覆盖度差了一步。