性能调优是 GaussDB 知识体系中占比最大的一块。本文整理性能诊断的核心思路——等待事件分类、慢 SQL 的排查链路以及内存、WAL、Vacuum 等系统级调优的关键参数。一、调优的基本思路性能调优可以看作一个分层的金字塔自上而下成本越高、效果越不明显硬件提升 → 内存/IO/网络优化 → OS 内核参数 → 数据库系统 → 数据库 SQL → 业务系统调优的首要工作是确定调优范围——是系统级问题还是单条 SQL 的问题。因为只有大表或复杂查询才最容易产生性能问题定位到具体的 SQL 才能对症下药。二、等待事件等待事件是定位性能瓶颈的关键入口主要分为四大类IO / LOCK / LWLOCK / STATUS。几个高频等待事件及其含义等待事件含义wait cmd等待应用侧发数据压力尚未到内核none正在执行无明显瓶颈LOGCTRL_SLEEP数据库流控pooler create connCN 向 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 / IOcheckpoint_segments每个日志文件 16MB。增量检查点需开启enable_incremental_checkpoint和enable_double_write。recovery_time_target流控参数设为 0 表示关闭流控。5.3 VacuumVACUUM 的职责包括清理死元组和对应索引项、冻结旧 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。