PostgreSQL性能下降是数据库运维中常见的问题，排查过程需要遵循从外到内、从整体到局部的逻辑，逐步缩小问题范围，最终定位到根因。一般可以按照系统层、数据库实例层、语句层的顺序开展排查工作。
一、系统层资源排查
首先确认服务器本身的资源是否存在瓶颈，数据库性能下降很多时候是底层资源不足导致的。可以通过系统命令查看CPU、内存、磁盘、网络的使用情况。
1. CPU使用率检查
使用top命令查看CPU占用，如果PostgreSQL进程CPU使用率长期超过80%，说明可能存在大量计算型查询或者索引缺失导致的全表扫描。
2. 内存使用情况
通过free -h查看内存，重点关注可用内存和swap使用情况，如果swap被频繁使用，说明物理内存不足，需要调整PostgreSQL的共享内存配置或者扩容服务器内存。
3. 磁盘IO检查
使用iostat -x 1查看磁盘IO状态，关注%util指标，如果该值长期接近100%，说明磁盘IO达到瓶颈，可能是大量随机读写或者日志写入过频繁导致。
二、数据库实例层排查
系统资源无异常的情况下，需要排查PostgreSQL实例本身的运行状态，查看是否存在配置不合理或者内部异常。
1. 查看数据库活动连接
登录PostgreSQL后执行以下查询，查看当前所有连接的状态，排查是否存在大量空闲连接或者长时间运行的异常连接：
-- 查看所有连接状态 SELECT pid, usename, application_name, client_addr, state, now() - query_start AS duration, query FROM pg_stat_activity WHERE state != 'idle';
2. 检查锁等待情况
如果业务出现卡顿，可能是存在锁等待导致，执行以下查询查看当前的锁冲突：
-- 查看锁等待信息 SELECT a.pid AS blocked_pid, a.usename AS blocked_user, b.pid AS blocking_pid, b.usename AS blocking_user, a.query AS blocked_query FROM pg_locks l1 JOIN pg_stat_activity a ON l1.pid = a.pid JOIN pg_locks l2 ON l1.locktype = l2.locktype AND l1.database IS NOT DISTINCT FROM l2.database AND l1.relation IS NOT DISTINCT FROM l2.relation AND l1.page IS NOT DISTINCT FROM l2.page AND l1.tuple IS NOT DISTINCT FROM l2.tuple AND l1.virtualxid IS NOT DISTINCT FROM l2.virtualxid AND l1.transactionid IS NOT DISTINCT FROM l2.transactionid AND l1.classid IS NOT DISTINCT FROM l2.classid AND l1.objid IS NOT DISTINCT FROM l2.objid AND l1.objsubid IS NOT DISTINCT FROM l2.objsubid JOIN pg_stat_activity b ON l2.pid = b.pid WHERE l1.granted = false;
3. 检查数据库配置参数
不合理的配置参数会直接影响性能，重点检查以下参数：
- shared_buffers：共享内存缓冲区大小，一般建议设置为物理内存的25%左右
- work_mem：每个查询操作可用的内存，过大会导致内存溢出，过小会导致临时文件写入磁盘
- max_connections：最大连接数，过高的连接数会增加资源开销，建议结合连接池使用
- effective_cache_size：优化器假设可用的磁盘缓存大小，影响查询计划的生成
三、慢查询排查与优化
慢查询是PostgreSQL性能下降的最常见原因，需要定位到具体的问题SQL进行优化。
1. 开启慢查询日志
修改postgresql.conf配置文件，开启慢查询记录：
# 记录执行时间超过1秒的查询 log_min_duration_statement = 1000 # 慢查询日志输出到文件 logging_collector = on log_directory = 'pg_log' log_filename = 'postgresql-%Y-%m-%d.log'
修改后执行pg_ctl reload重载配置即可生效。
2. 分析慢查询执行计划
拿到慢查询SQL后，使用EXPLAIN ANALYZE命令查看执行计划，分析性能瓶颈：
-- 分析查询执行计划，实际执行SQL并返回真实耗时 EXPLAIN ANALYZE SELECT * FROM user_table WHERE age > 18 AND city = '北京';
重点关注执行计划中的以下信息：
- 是否有Seq Scan（全表扫描），如果是大表全表扫描，需要检查对应查询条件是否有索引
- 索引是否被正确使用，是否存在索引失效的情况
- 是否存在嵌套循环连接过多、排序操作使用临时磁盘文件等问题
3. 索引优化建议
根据查询条件创建合适的索引，同时避免冗余索引：
-- 创建联合索引，覆盖查询条件中的字段 CREATE INDEX idx_user_age_city ON user_table(age, city); -- 查看表中冗余索引 SELECT indexname, tablename, indexdef FROM pg_indexes WHERE schemaname = 'public' ORDER BY tablename;
四、常见性能问题处理逻辑
| 问题现象 | 可能原因 | 解决方案 |
|---|---|---|
| 查询响应突然变慢 | 新增查询缺少索引、统计信息过期 | 创建对应索引、执行ANALYZE更新统计信息 |
| 写入操作变慢 | 大量索引写入开销、wal日志写入频繁 | 删除不必要的索引、调整wal相关配置参数 |
| 数据库连接数飙升 | 连接池配置不合理、长事务未释放 | 调整连接池配置、排查并终止长时间运行的事务 |
| CPU使用率持续过高 | 大量全表扫描、复杂聚合查询 | 优化查询SQL、添加合适索引、拆分复杂查询 |
五、定期维护建议
为了避免PostgreSQL性能下降，建议定期开展以下维护工作：
- 定期执行
VACUUM和ANALYZE命令，清理死元组并更新统计信息 - 定期监控数据库核心指标，建立性能基线，出现偏离时及时排查
- 大表建议定期做分区，减少单表数据量，提升查询效率
- 生产环境建议开启逻辑复制或者物理备份，避免数据异常导致的性能问题
PostgreSQL性能排查数据库优化慢查询分析修改时间：2026-06-23 21:34:03