首先确认PostgreSQL是否为CPU飙升主因，使用top、htop、vmstat等工具排查系统级负载；接着通过pg_stat_statements扩展定位高耗时或高调用频率的SQL查询；结合pg_stat_activity查看活跃会话，终止长时间运行的查询；利用EXPLAIN (ANALYZE, BUFFERS)分析执行计划，检查全表扫描、嵌套循环、排序哈希落盘等问题，优化缺失索引；评估并发连接数与max_connections关系，避免过多连接导致上下文切换开销；合理配置work_mem、maintenance_work_mem和effective_cache_size等参数，减少资源争用；建议开启log_min_duration_statement记录慢查询，便于后续分析。
PostgreSQL CPU 使用率飙升通常会影响数据库响应速度，甚至导致服务不可用。排查这类问题需要从系统、数据库进程、SQL 查询等多个层面入手，快速定位瓶颈所在。
检查系统级 CPU 使用情况
先确认是 PostgreSQL 导致的 CPU 占用高，还是其他进程。使用以下命令查看整体负载：
top 或 htop观察是否有多个 postgres 进程占用大量 CPU。如果发现某个特定进程 CPU 高，记下其 PID，后续可用于关联 SQL 查询。
也可通过 vmstat 1 或 sar -u 1 查看 CPU 使用趋势，判断是否为突发或持续性高峰。
定位高 CPU 的 SQL 查询
PostgreSQL 提供了多种方式查找执行耗时长或执行频繁的 SQL。
启用并查看 pg_stat_statements 扩展（需在配置中开启）：
- 确保 postgresql.conf 中包含：
shared_preload_libraries = 'pg_stat_statements'
pg_stat_statements.track = all - 重启数据库后执行：
SELECT query, calls, total_time, mean_time FROM pg_stat_statements ORDER BY mean_time DESC LIMIT 10;
重点关注 mean_time 高或 calls 频繁的 SQL，这些可能是 CPU 消耗大户。
结合 pid 查看当前活跃的高负载会话：
SELECT pid, query, state, backend_start, query_start FROM pg_stat_activity WHERE state = 'active' AND query NOT LIKE '%pg_stat_activity%' ORDER BY query_start;
找到长时间运行的查询，可考虑终止：
SELECT pg_terminate_backend(pid);
分析执行计划与索引使用
对定位到的高耗时 SQL，使用 EXPLAIN (ANALYZE, BUFFERS) 查看实际执行计划：
EXPLAIN (ANALYZE, BUFFERS) your_query;
关注以下几点：
- 是否出现全表扫描（Seq Scan）且扫描行数巨大
- 嵌套循环（Nested Loop）次数过多
- 排序（Sort）或哈希（Hash）操作是否在内存外进行（写入磁盘）
- 是否存在缺失的索引建议
为高频过滤字段或 JOIN 条件创建合适索引，可显著降低 CPU 消耗。
检查配置与并发连接
过多的并发连接可能导致上下文切换频繁，增加 CPU 开销。
查看当前连接数：
SELECT count(*) FROM pg_stat_activity;
若连接数接近 max_connections，考虑使用连接池（如 PgBouncer）减少后端进程数量。
同时检查关键参数：
- work_mem：设置过高会导致单个查询占用多内存，引发 swap；过低则迫使排序/哈希落盘，增加 CPU 负担
- maintenance_work_mem：影响 VACUUM、CREATE INDEX 等操作，大对象处理时可能短暂拉高 CPU
-
effective_cache_size：影响执行计划选择，设置
不合理可能导致走错索引
不合理可能导致走错索引根据实际内存合理调整，避免资源争用。
基本上就这些。CPU 飙升多数源于慢查询或资源争用，通过系统监控、pg_stat_statements 和执行计划分析，能快速定位根因。日常建议开启慢查询日志（log_min_duration_statement），便于事后追溯。
