ORDER BY 性能优化核心是让数据库走索引排序而非运行时计算，需确保排序字段有匹配顺序的复合索引、避免函数导致索引失效、ASC/DESC与索引定义一致、配合LIMIT提前终止排序，并在深分页时改用游标分页。
ORDER BY 是 SQL 中最常被忽视性能瓶颈之一，尤其在数据量大、排序字段无索引或涉及多表 JOIN 时，容易引发 filesort、临时表甚至内存溢出。优化核心在于减少排序开销，让数据库尽可能走索引完成排序，而非运行时计算。
确保排序字段有合适的索引
MySQL 和 PostgreSQL 等主流数据库能利用索引的有序性跳过实际排序操作——前提是 ORDER BY 字段顺序与索引列顺序一致，且 WHERE 条件能有效命中该索引前缀。
- 例如：查询 SELECT * FROM orders WHERE status = 'paid' ORDER BY created_at DESC，应建立复合索引 (status, created_at)，而非仅 (created_at)
- 避免在排序字段上使用函数或表达式，如 ORDER BY UPPER(name) 会使索引失效；如需大小写不敏感排序，可建函数索引（MySQL 8.0+ 支持）或使用生成列
- 升序（ASC）/降序（DESC）需与索引定义匹配；MySQL 8.0+ 支持混合方向索引（如 (a ASC, b DESC)），但旧版本中所有方向必须一致才可复用索引
限制结果集，避免全表排序
当业务只需最新 10 条记录时，执行 ORDER BY ... LIMIT 10 比先取全部再应用 LIMIT 更高效——数据库可在找到足够行后提前终止排序。但注意：LIMIT 必须与 ORDER BY 同时出现，且不能被子查询或 UNION 干扰逻辑执行顺序。
- 慎用 SELECT * ORDER BY x LIMIT N：若 x 无索引，仍会扫描全表并排序；优先保证排序字段索引覆盖
- 分页深度较大时（如 LIMIT 10000, 20），即使有索引也可能变慢；改用“游标分页”（基于上一页最后值继续查）更稳定，例如 WHERE created_at
避免 SELECT * + 多表 JOIN 后排序
JOIN 多张大表后再排序，极易触发临时表和 filesort。应尽量将排序下推到单表，或通过覆盖索引减少回表成本。
- 若只按主表字段排序，考虑先查主表 ID（带 LIMIT），再用 IN 或 JOIN 补充关联字段，避免大结果集参与排序
- 为减少回表，给排序字段+查询字段建联合索引，例如需要 SELECT id, title, author FROM posts ORDER BY publish_time DESC，可建索引 (publish_time, id, title, author)（覆盖索引）
- 对 JOIN 结果排序，检查是否能利用被驱动表的索引；有时调整 JOIN 顺序或改用 EXISTS 替代 LEFT JOIN 可改善排序路径
监控与识别排序瓶颈
别只看执行时间，要关注执行计划中是否出现 Using filesort 或 Using temporary ——这是排序未走索引的明确信号。
- MySQL 中用 EXPLAIN FORMAT=TRADITIONAL 查看 Extra 列；PostgreSQL 用 EXPLAIN (ANALYZE, BUFFERS) 观察 Sort Node 的 sort method（external merge 表示磁盘排序，代价高）
- 开启慢查询日志并设置 log_queries_not_using_indexes = ON，快速定位缺失索引的排序语句
- 对高频排序查询做响应时间基线监控，结合 QPS 突增排查隐式类型转换（如字符串字段 vs 数字条件）导致索引失效的问题
