SQL 多字段排序慢的核心原因是排序字段未被索引有效覆盖或索引顺序与 ORDER BY 不一致；必须创建字段顺序严格匹配的复合索引，避免函数、混合升降序及类型不一致等问题。
SQL 报表多字段排序慢，核心问题往往出在排序字段没有被索引有效覆盖，或者索引顺序与 ORDER BY 子句不匹配。
排序字段必须按顺序包含在复合索引中
MySQL、PostgreSQL 等主流数据库对多字段排序（如 ORDER BY a, b, c）要求索引字段顺序严格一致。只有当索引定义为 (a, b, c) 时，才能高效支持该排序；若索引是 (a, c, b) 或 (b, a, c)，数据库大概率会放弃使用索引做排序，转而执行文件排序（Using filesort），导致性能陡降。
- 检查执行计划：用 EXPLAIN SELECT … ORDER BY a,b,c，确认 Extra 列是否出现 Using filesort
- 创建匹配索引：例如查询常按 status, created_at, id 排序，就建索引 INDEX idx_sort (status, created_at, id)
- 避免冗余字段：索引末尾可加查询中需要的等值过滤字段（如 WHERE status = ‘done’），但排序字段顺序不可调换
WHERE 条件影响排序索引的选择
如果查询带 WHERE 过滤（如 WHERE type = ‘report’ AND status IN (‘pending’,’done’)），理想索引应把等值条件字段放在最左，再接排序字段。例如：
- WHERE type = ? AND status = ? ORDER BY created_at, id → 推荐索引：(type, status, created_at, id)
- WHERE status IN (…) 是范围查询，它之后的字段无法用于排序（索引最左前缀原则），此时 status 不宜放在排序字段之前
- 若 status 是 IN 多值或 LIKE 左模糊，考虑将高区分度等值字段前置，再接排序字段
避免在排序字段上使用函数或表达式
一旦 ORDER BY 中出现 DATE(created_at)、UPPER(name) 或 col + 1 等计算，即使有索引也无法利用，必然触发 filesort。
- 改写方式：提前物化计算字段并建索引，例如增加列 created_date DATE AS (DATE(created_at)) STORED，再对其建索引
- 或在应用层处理格式化，SQL 层只对原始字段排序
- 时间范围排序慎用函数：用 created_at >= ‘2024-01-01’ AND created_at < ‘2024-02-01’ 替代 YEAR(created_at) = 2024
注意数据类型和排序方向的一致性
索引默认按升序存储。若查询写成 ORDER BY a ASC, b DESC，而索引是 (a, b)（默认均为 ASC），则 b 的 DESC 可能导致索引失效（尤其 MySQL 8.0 以前）。解决方案：
- MySQL 8.0+ 支持降序索引：INDEX idx_asc_desc (a ASC, b DESC)
- 旧版本建议统一排序方向，或拆分查询逻辑，避免混合 ASC/DESC
- 确保字段类型一致：比如 VARCHAR 字段排序时 collation 不匹配，也可能绕过索引
