定位和治理PostgreSQL业务热点需按“监控发现→日志精确定位→执行计划分析→优化调整”流程推进。1. 通过pg_stat_activity、QPS/TPS及CPU/I/O监控识别异常负载；2. 启用慢查询日志（log_min_duration_statement≥500ms）精准捕获高频或耗时SQL；3. 使用EXPLAIN (ANALYZE, BUFFERS)分析执行计划，排查全表扫描、高成本节点、WorkMem溢出或锁等待；4. 针对性创建索引、重写SQL（避免函数索引）、优化事务以消除瓶颈。
定位和治理PostgreSQL中的业务热点，关键在于快速识别出消耗大量资源的查询或事务，并理解其背后的业务逻辑。核心思路是“监控发现 -> 日志精确定位 -> 执行计划分析 -> 优化调整”。
1. 实时监控：发现异常流量
通过实时监控指标，第一时间感知数据库负载升高。
-
连接数与活跃会话：持续观察
pg_stat_activity视图。如果state = 'active'的会话数量远超正常水平，说明有大量并发查询正在执行，可能出现了热点。 - QPS/TPS：查询每秒请求数（QPS）或事务每秒处理数（TPS）的突然飙升，是业务流量激增的直接信号。
- CPU与I/O：结合操作系统监控，如果CPU使用率或磁盘I/O等待时间（iowait）持续处于高位，而连接数并未显著增加，则可能是少数几个复杂查询在消耗资源。
2. 慢查询日志：精确定位“元凶”SQL
慢查询日志是定位热点SQL最精准的工具。确保在postgresql.conf中正确配置：
-
log_min_duration_statement = 500ms：记录所有执行时间超过500毫秒的SQL。这个阈值可以根据业务的SLA进行调整。 -
log_line_prefix = '%t [%p]: [%l-1] user=%u,db=%d,app=%a,client=%h '：在日志开头添加丰富的上下文信息，方便追踪到具体的用户、数据库、应用和客户端IP。
当热点发生时，立即检查慢查询日志文件。出现频率最高、执行时间最长的SQL语句，极有可能就是导致问题的根源。重点关注带有WHERE条件但未走索引的查询，或者执行INSERT/UPDATE/DELETE操作的DML语句。
3. 分析执行计划：诊断性能瓶颈
对于定位到的可疑SQL，使用EXPLAIN (ANALYZE, BUFFERS)命令获取其实际执行计划。
- Seq Scan (全表扫描)：如果本应走索引的查询却进行了全表扫描，说明索引缺失、失效或统计信息过期。这是最常见的性能杀手。
-
高成本节点：关注执行计划中“cost”和“actual time”最高的操作。如果是
Hash Join且actual rows远大于预期，说明关联条件选择性差，需要优化查询条件或索引。 -
内存溢出：如果看到
WorkMem used: XXXkB (disk-based)，表示排序或哈希操作超出了work_mem限制，被迫使用磁盘临时文件，速度会急剧下降。 -
锁等待：检查
pg_locks和pg_blocking_pids()函数，看是否有会话因行锁或表锁而长时间阻塞，这通常由未提交的长事务或低效的更新操作引起。
4. 治理与优化：针对性解决
根据诊断结果，采取相应的治理措施。
-
创建或优化索引：为查询的过滤字段(
WHERE)、连接字段(JOIN)和排序字段(ORDER BY)创建合适的B-Tree索引。对于特定场景，考虑使用部分索引（如CREATE INDEX ... WHERE status = 'active'）或表达式索引。 -
重写SQL：避免在索引列上使用函数或计算（如
WHERE YEAR(create_time) = 2025），改用范围查询（WHERE create_time >= '2025-01-01' AND create_time ）。将复杂的子查询改写为LATERAL JOIN或CTE，让优化器有更好的选择。 -
调整配置：适当增加
shared_buffers和work_mem以提升缓存命中率和复杂操作性能。启用autovacuum并合理配置，防止表膨胀影响查询效率。 - 业务层限流：如果确认是突发的恶意请求或程序BUG导致的热点，应在应用网关或服务层实施限流策略，保护数据库实例。
基本上就这些，从监控到日志再到执行计划，层层下钻，问题不难解决。
