性能调优是 GaussDB 知识体系中占比最大的一块。本文整理性能诊断的核心思路------等待事件分类、慢 SQL 的排查链路，以及内存、WAL、Vacuum 等系统级调优的关键参数。
一、调优的基本思路
性能调优可以看作一个分层的金字塔，自上而下成本越高、效果越不明显：
硬件提升 → 内存/IO/网络优化 → OS 内核参数 → 数据库系统 → 数据库 SQL → 业务系统调优的首要工作是确定调优范围------是系统级问题还是单条 SQL 的问题。因为只有大表或复杂查询才最容易产生性能问题，定位到具体的 SQL 才能对症下药。
二、等待事件
等待事件是定位性能瓶颈的关键入口，主要分为四大类：IO / LOCK / LWLOCK / STATUS。
几个高频等待事件及其含义：
| 等待事件 | 含义 |
|---|---|
wait cmd |
等待应用侧发数据，压力尚未到内核 |
none |
正在执行，无明显瓶颈 |
LOGCTRL_SLEEP |
数据库流控 |
pooler create conn |
CN 向 DN 建连慢 |
wait node |
等待其他节点（该节点是瓶颈） |
wait wal sync |
事务提交等待备机日志下盘 |
Sort-write file |
排序下盘（考虑增大 work_mem） |
三、慢 SQL 定位链路
当遇到 SQL 长时间不结束，建议按以下顺序排查：
- 使用
pg_thread_wait_status或 ASP 查看 Top Wait Event； - 出现大量锁等待时，通过 ASP 的
block sessionid查找阻塞关系； - 若执行时间超过
log_min_duration_statement阈值，从 Full SQL 视图查看执行计划； - 获取完整业务 SQL，使用
EXPLAIN定位计划中的瓶颈，并结合统计信息分析； - 收集对应时间段的 CPU、内存、I/O 等系统资源情况。
一个重要的原则：不要把直接重启数据库作为首选处理方法，应先保留现场证据，再解除阻塞或处理异常会话。
关于 log_min_duration_statement 参数：它用于设置慢 SQL 记录阈值，SQL 执行时间达到或超过该阈值后才会被记录。阈值过大可能漏掉需要分析的 SQL，阈值过小则会产生大量日志。
四、判断压力在内核侧还是业务侧
判断压力位置时，需要结合以下信息：
- 客户近期业务和系统变化；
- 数据库主机 CPU 使用率；
pg_stat_activity中非 idle 会话数量；- 线程池状态中的 session 信息；
- OPS 中的活跃会话数量。
一个典型判断：如果数据库 CPU 使用率不足 10%，活跃会话只有个位数，说明压力可能没有传到数据库内核，此时应优先排查应用资源、网络时延、连接情况以及应用处理结果的速度。
五、系统级调优关键参数
5.1 内存
shared_buffers：建议设为最大可用内存的 40%。work_mem：控制排序、Hash、聚合等查询算子下盘前的内存，复杂查询的总内存会是它的好几倍。- 线程池
thread_num：推荐值为 CPU 核数的 6~8 倍。
5.2 WAL / IO
checkpoint_segments：每个日志文件 16MB。- 增量检查点需开启
enable_incremental_checkpoint和enable_double_write。 recovery_time_target：流控参数，设为 0 表示关闭流控。
5.3 Vacuum
VACUUM 的职责包括：清理死元组和对应索引项、冻结旧 txid、更新 FSM/VM、更新统计信息等。
两个互相制约的参数：
vacuum_cost_limit越大，VACUUM 效率越高，但对业务 I/O 影响越大；vacuum_cost_delay越大，对业务影响越小，但 VACUUM 越慢。
小结
- 调优先定位范围（系统级 vs 单 SQL）。
- 等待事件分 IO / LOCK / LWLOCK / STATUS 四类。
- 慢 SQL 排查顺序：等待事件 → 阻塞链 → 执行计划 → 系统资源。
- 数据库没压力时，优先排查业务、应用和网络侧。
shared_buffers建议 40%，线程池线程数 CPU×6~8。