sql索引加速order by需满足字段顺序完全匹配、最左前缀原则及排序方向一致；where+order by组合时，等值条件字段应前置，范围条件会截断后续排序能力；避免select *以防回表开销过大导致索引失效。
SQL 索引能显著加速 ORDER BY 查询，但前提是索引字段顺序与 ORDER BY 子句完全匹配，且满足最左前缀原则。
索引字段顺序必须严格匹配 ORDER BY
数据库只能利用索引的有序性来避免排序操作。如果查询是 ORDER BY a, b，那么只有 (a, b) 或 (a, b, c) 这样的复合索引才可能被使用；(b, a) 或 (a) 单独存在则无法支持按 a, b 排序。
- ✅ 有效：查询
ORDER BY user_id, created_at→ 索引(user_id, created_at) - ❌ 无效：同样查询 → 索引
(created_at, user_id)或仅(user_id) - ⚠️ 注意：即使
WHERE条件用了user_id = ?，若索引是(user_id, created_at)，仍可直接用索引完成排序，无需额外排序步骤
WHERE + ORDER BY 组合时，索引需覆盖筛选和排序需求
当查询同时含 WHERE 和 ORDER BY，理想索引应把 WHERE 中的等值条件字段放前面，再接 ORDER BY 字段（注意：范围条件如 >、BETWEEN 会截断索引后续字段的排序能力）。
- ✅ 推荐：查询
WHERE status = 'active' ORDER BY created_at DESC→ 索引(status, created_at) - ❌ 低效：相同查询 → 索引
(created_at, status)（排序字段在前，status 等值过滤无法利用索引有序性） - ⚠️ 范围陷阱：查询
WHERE age > 25 ORDER BY name→ 即使有(age, name)索引，name部分也无法用于排序，因为age > 25后索引中name不再全局有序
DESC/ASC 显式声明影响索引选择（尤其多字段时）
MySQL 8.0+ 和 PostgreSQL 支持在索引中定义字段升序或降序。若 ORDER BY a ASC, b DESC，而索引定义为 (a ASC, b DESC)，则可直接使用；若索引是 (a, b)（默认均为 ASC），则对 b DESC 可能不走索引排序，或需反向扫描（效率较低）。
- ✅ 匹配：查询
ORDER BY category ASC, price DESC→ 索引(category ASC, price DESC) - ⚠️ 兼容但非最优：相同查询 → 索引
(category, price)（MySQL 8.0+ 可能用，但老版本或某些场景仍触发 filesort） - ? 建议：对固定方向的排序查询，在建复合索引时显式标注
ASC/DESC，提高确定性
避免 SELECT * 配合 ORDER BY 索引失效
即使 ORDER BY 走了索引，若查询返回大量非索引字段（尤其是大字段如 TEXT、JSON），优化器可能放弃使用索引排序，转而全表扫描 + 内存排序（filesort），因为回表成本过高。
- ✅ 更优写法：只查必要字段，例如
SELECT id, title FROM posts ORDER BY created_at LIMIT 10 - ❌ 风险写法：
SELECT * FROM posts ORDER BY created_at LIMIT 10（尤其当表有大字段时） - ? 补充：可通过
EXPLAIN查看Extra列是否含Using filesort，这是排序未走索引的关键信号
