SQL慢查询致CPU过高主因是排序、哈希连接等算子消耗大，根源于数据分布不均、索引缺失及排序设计不合理；需通过执行计划定位Sort等节点，结合work_mem调优、精准索引覆盖（字段顺序与方向严格匹配）及统计信息更新来优化。
SQL慢查询导致CPU过高，通常是因为执行计划中某些算子（如排序、哈希连接、嵌套循环）消耗大量CPU资源。核心问题不在SQL写法本身，而在数据分布、索引缺失和排序逻辑设计不合理。
排序（Sort）是CPU杀手的常见原因
当查询含 ORDER BY、DISTINCT、GROUP BY 或窗口函数（如 ROW_NUMBER()）时，数据库常需在内存或磁盘完成全量排序。若排序字段无索引、数据量大、内存不足（work_mem 小），就会触发外部归并排序，频繁读写临时文件，CPU飙升。
- 检查执行计划中是否出现 Sort 节点，看 Actual Total Time 和 Plans 子节点耗时占比
- 用 EXPLAIN (ANALYZE, BUFFERS) 观察是否发生 External Sort（表示落盘）
- 临时调高 work_mem（如从 4MB → 64MB）可验证是否因内存不足导致排序劣化（注意：仅会话级生效，勿全局滥用）
索引无法覆盖排序的典型场景
即使有索引，也不代表能避免排序。只有当 ORDER BY 字段顺序 + 方向 与索引定义完全匹配，且 WHERE 条件能有效利用该索引前导列 时，才可能走索引扫描跳过排序。
- 错误示例：
CREATE INDEX idx_user_age_name ON users(age, name);，但查询是SELECT * FROM users WHERE name = 'Alice' ORDER BY age;→ 索引无法用于排序（name 非前导列） - 正确优化：
CREATE INDEX idx_user_name_age ON users(name, age);，配合WHERE name = 'Alice' ORDER BY age可直接索引扫描+无需排序 - 复合排序多字段时，索引字段顺序必须严格一致，
ORDER BY a ASC, b DESC需对应INDEX(a ASC, b DESC)
算子成本误判：别只盯住“最慢”的节点
执行计划里标红的“高 cost”节点未必是根因。例如一个 Nested Loop 外层返回1000行，内层每次执行需查10万行，总代价是1000×10万=1亿次操作——表面看内层Index Scan单次快，但放大后才是CPU瓶颈。
- 重点看 Actual Rows × Loops 的乘积，比 Actual Total Time 更反映真实计算压力
- 对高频嵌套循环，优先考虑改写为 JOIN 或添加覆盖索引，减少回表/重复计算
- 统计信息不准会导致优化器选错算子（比如误估小表变大表），定期执行 ANALYZE table_name
排序优化的务实路径
不追求一步到位，先定位再收敛：
- 用 pg_stat_statements 找出 CPU 时间 TopN 的慢查询
- 对每条SQL跑 EXPLAIN (ANALYZE, BUFFERS)，聚焦 Sort、Hash、Nested Loop 节点的 Rows 和 Loops
- 优先加索引覆盖排序+过滤，其次考虑分页优化（如用游标替代 OFFSET）、结果集裁剪（减少 SELECT *）
- 业务允许时，用物化视图或应用层缓存规避实时排序
