order by 性能问题主因是索引未被利用，需确保索引列顺序、方向及where条件严格匹配；避免函数排序、合理使用游标分页、显式处理null、拆分json字段建索引。
ORDER BY 没走索引，查询变慢怎么办
绝大多数 ORDER BY 性能问题，根源是数据库没用上索引排序能力。MySQL/PostgreSQL 都要求索引列顺序、方向、WHERE 条件三者严格匹配，稍有不一致就退化成 filesort。
实操建议：
- 检查执行计划：用
EXPLAIN看Extra字段是否含Using filesort—— 出现即表示排序未走索引 - 复合索引必须左前缀匹配：比如
ORDER BY user_id, created_at DESC，索引得建为(user_id, created_at)；若 WHERE 里只用了status = 'active'，这个索引基本无效 - ASC/DESC 要显式对齐：MySQL 8.0+ 支持混合方向索引，但老版本只支持全 ASC 或全 DESC；
ORDER BY a ASC, b DESC在 5.7 下无法用(a,b)索引 - 避免在排序字段上用函数：
ORDER BY UPPER(name)会强制 filesort；想大小写不敏感排序，改用对应 collation（如utf8mb4_0900_as_cs）更高效
分页深翻（LIMIT offset, size）卡顿怎么破
当 offset 超过几万，即使有索引，数据库仍要扫描前面所有行，ORDER BY + LIMIT 的代价是 O(offset)。
实操建议：
- 用游标分页替代 offset：记录上一页最后一条的排序键值，下一页查
WHERE sort_col > last_value ORDER BY sort_col LIMIT 20 - 禁止前端传超大 offset：加后端校验，比如
if offset > 10000 { return error } - 如果必须跳转到某页（如搜索结果页码），优先考虑用覆盖索引减少回表，或把热点页数据预热进缓存
ORDER BY 多字段时 NULL 值干扰排序结果
NULL 在排序中默认排最前（ASC）或最后（DESC），但不同数据库行为不一致（如 PostgreSQL 默认 NULLS LAST，MySQL 不支持该语法），容易导致分页错位或前端渲染异常。
实操建议：
- 显式控制 NULL 位置：PostgreSQL 写
ORDER BY status NULLS LAST；MySQL 只能绕过，比如用ORDER BY (status IS NULL), status - 业务字段尽量设
NOT NULL：尤其是用于排序/分页的字段，避免 NULL 引发逻辑分支和性能抖动 - 注意 ORM 自动生成的 SQL：Django/SQLAlchemy 可能忽略 NULL 行为差异，上线前务必在目标数据库验证排序一致性
JSON 字段里提取值再排序，性能掉坑里了
像 ORDER BY JSON_EXTRACT(meta, '$.score') 这类写法，每次都要解析整个 JSON 文本，无法走索引，且 MySQL 5.7+ 的函数索引也仅支持确定性函数。
实操建议：
- 高频排序字段别塞 JSON：拆成独立列，加普通索引或生成列索引（MySQL 5.7+ 支持
GENERATED COLUMN + INDEX） - 真要用 JSON 排序，先建函数索引（MySQL）：
ALTER TABLE t ADD score_gen INT AS (JSON_EXTRACT(meta, '$.score')) STORED;，再对score_gen建索引 - PostgreSQL 可建表达式索引：
CREATE INDEX idx_score ON t ((meta->>'score')::int);，但注意类型转换失败会报错，需确保数据干净
真正卡住性能的往往不是 ORDER BY 本身，而是它暴露了索引设计断层、数据模型冗余、或者边界条件没兜住。尤其注意那些“看起来能走索引”的组合——实际执行计划一验就露馅。
