1. 性能优化导论

在核心业务系统中，PostgreSQL 往往不是“一个可选的数据库”，而是订单、支付、库存、账务、风控等关键链路的最终事实来源。它同时承担三类角色：第一，作为事务一致性保障者，通过 MVCC、WAL、行级锁和约束保证数据不丢、不重、不乱；第二，作为并发访问协调者，在大量短事务与少量长查询并存时，依靠锁、快照和连接管理维持吞吐；第三，作为业务查询执行引擎，把 SQL 解析为执行计划，再通过索引、连接、排序、聚合等算子返回结果。性能优化不是单纯“让 SQL 跑得更快”，而是让这三类角色在业务目标下同时成立。

因此，性能问题必须先分类，再谈优化。常见问题可归为四类：资源瓶颈（CPU、内存、磁盘 I/O、网络带宽被耗尽）、锁与并发冲突（行锁等待、表锁阻塞、死锁、长事务拖住 vacuum）、执行计划劣化（统计信息过期、索引缺失或失效、连接方式选择错误、估算行数严重偏离）、架构与访问模式问题（连接数过多、热点行更新、大表全扫、N+1 查询、批量写入与在线查询互相干扰）。分类的意义在于：不同类别对应不同工具和不同责任人，盲目加索引或调参数往往只掩盖症状。

衡量指标要分层看。第一层是业务指标：订单创建成功率、支付回调延迟、库存扣减 P99 响应时间。第二层是数据库指标：QPS/TPS、平均与 P95/P99 查询延迟、活跃连接数、锁等待时间、死锁次数、缓存命中率、WAL 生成速率、检查点频率、autovacuum 滞后。第三层是资源指标：CPU 使用率、内存命中与换页、磁盘 IOPS 与延迟、网络往返。三层指标必须能相互解释：业务 P99 升高，通常能在数据库层看到锁等待或慢查询，在资源层看到 I/O 饱和或 CPU 争用。

下面这张图把“业务请求 → 数据库内部处理 → 资源消耗 → 指标观测”串成一条信号链，帮助你在排障时快速定位问题落在哪一层。图中同时标出四类性能问题最常出现的环节，以及对应的首要观测指标。

有了这条信号链，优化工作就有了明确的起点。实际排障时，建议按“业务指标异常 → 数据库指标定位环节 → 资源指标确认瓶颈 → 回到问题分类选择手段”的顺序推进，而不是一上来就改参数或加索引。例如，支付回调 P99 从 180ms 升到 900ms，先看数据库层是否出现锁等待或慢查询增多；若锁等待集中在某张订单表，再检查是否有长事务未提交或热点行更新；若资源层显示磁盘 I/O 延迟升高，则要判断是 WAL 写入、检查点还是大查询排序导致。

优化目标应当可量化、可验证。一个可参考的示例目标是：核心交易链路 P99 响应时间不超过 200ms，数据库 CPU 使用率长期低于 70%，锁等待时间占比低于 1%，死锁次数为 0，缓存命中率高于 99%。这些数值是示例性目标，实际应以业务 SLA 和压测基线为准。衡量时要注意：平均值会掩盖长尾，必须看 P95/P99；QPS 高不代表体验好，若 P99 同时恶化，说明系统已接近饱和。

最后要建立“基线—变更—验证”的闭环。上线前记录基线指标，变更后在同一业务压力下对比 P99、QPS、锁等待和资源使用率；若指标未改善或出现新的瓶颈，应回滚并重新分类问题。性能优化不是一次性动作，而是伴随业务增长持续进行的工程实践。只有把业务目标、数据库行为和资源消耗放在同一张图上观察，才能避免“局部优化、整体退化”的常见陷阱。