2      GaussDB数据库性能调优

2.1  总结

本文档围绕 GaussDB 数据库性能调优展开，核心涵盖系统级指标及性能调优、WDR 报告详解、SQL 优化三大模块：系统级指标通过三级指标体系（系统级：OS/CPU/ 内存 / 会话，对象级：库 / 表 / 索引 / 锁，应用级：事务 / SQL / 慢查询）及dbe_perf系列视图实现瓶颈定位；WDR 报告作为性能 “体检报告”，通过定时快照（默认 60 分钟）采集性能数据，生成包含 Summary（负载 / CPU/IO）和 Detail（SQL 统计 / 等待事件）的报告，支持集群 / 节点级分析；SQL 优化则基于SQL 执行机制（解析→优化→执行），通过算子控制（扫描 / 关联 / 物化算子）、调优工具（work_mem参数、Plan Hint）及业务适配（交易类 CN 轻量化、混合负载类 SMP/RLBT），解决数据倾斜、计划选择不当等问题，最终实现数据库整体性能提升。

2.2   思维导图（mindmap）

2.3  详细总结

一、系统级指标及性能调优

1. 三级指标体系（核心内容）

2. 性能瓶颈定位案例

             案例 1：索引不当：某 SQL 时延 1.2s，通过dbe_perf.stat_user_indexes发现无匹配索引，重建复合索引后时延降至 100ms 内；

             案例 2：集群性能不达标：通过dbe_perf.wait_events发现某 DN 等待DoubleWriteFileWrite事件，排查为备机 IO 瓶颈，更换存储后性能恢复；

             案例 3：应用版本问题：Benchmark 事务成功率抖动，通过dbe_perf.instance_time发现NET_SEND_TIME异常，升级应用版本后网络开销降低 50%。

二、WDR 报告详解

1. WDR 基础配置

2. 报告生成与限制

             生成步骤：

                          gsql 连接 postgres 库；

                          执行\a \t \o /path/cluster.html（指定输出路径）；

                          调用函数：select generate_wdr_report(begin_snap_id, end_snap_id, 'all', 'cluster', '');

             限制条件：

                                   快照间不可有节点重启、Drop Database、主备倒换；

                                   不可重置dbe_perf.statement视图。

3. 报告核心内容（表格）

4. 典型应用场景

             场景 1：响应时间分析：查看 Summary→Load Profile，若 P95 响应时间 > 1s，定位 Top SQL（Detail→SQL Statistics 按总时延排序）；

             场景 2：缓存命中率低：Summary→Instance Efficiency Percentages，若 Buffer 命中率 < 95%，调整shared_buffers参数；

             场景 3：异常等待：Detail→Wait Events，若STATUS wait cmd总时长过高，排查会话阻塞（关联dbe_perf.session_stat_activity）。

三、SQL 优化

1. SQL 执行机制与执行计划

             执行流程：

                          解析（Parser）：词法→语法分析生成语法树，语义分析生成查询树；

                          优化（Planner）：查询重写（简化 SQL）→路径生成→代价计算，选择最优计划；

                          执行（Executor）：按计划树调用算子，访问表 / 索引执行 SQL。

             执行计划查看：通过EXPLAIN命令，支持多选项：

                                    EXPLAIN (costs off)：不显示代价；

                                    EXPLAIN (analyze on)：执行 SQL 并显示实际耗时；

                                    EXPLAIN (nodes on)：显示执行节点。

2. 核心算子分类（表格）

3. 关键调优工具与策略

（1）参数调优

（2）Plan Hint（手工干预计划）

（3）业务适配调优

4. 统计信息与分布式计划

             统计信息：优化器依赖的表 / 列数据分布信息，通过ANALYZE更新，存储于pg_statistics/pg_stats，核心指标包括列空值率、唯一值数、最常见值（MCV）；

             分布式计划：

                          下发 SQL 语句：各 DN 独立执行，无数据交互（如单表过滤）；

                          下发 SQL 计划：CN 生成计划，DN 执行并交互数据（如多表关联）；

                          下发部分 SQL：CN 执行部分逻辑，DN 执行基表扫描（极少数场景）。

2.4   关键问题

问题 1：如何通过系统级指标定位 GaussDB 集群的 CPU 瓶颈？需结合哪些视图和指标？

答案：定位 CPU 瓶颈需从 “系统级 CPU 使用” 和 “应用级 CPU 消耗” 两方面入手，核心步骤与视图如下：

             查看系统级 CPU 负载：

                                   调用视图dbe_perf.os_runtime，关注指标：NUM_CPU_CORES（CPU 核数）、BUSY_TIME（CPU 繁忙时间）、USER_TIME（用户态时间）、SYS_TIME（系统态时间）、IOWAIT_TIME（IO 等待时间）；

                                   若BUSY_TIME占比 > 80% 且IOWAIT_TIME占比 < 10%，说明 CPU 饱和（非 IO 导致）。

             定位 CPU 消耗来源：

                                   查看dbe_perf.instance_time，对比CPU_TIME（总 CPU 时间）与DB_TIME（作业有效时间），若CPU_TIME接近DB_TIME，说明 CPU 是瓶颈；

                                   查看dbe_perf.session_stat_activity，筛选state='active'的会话，按now()-query_start排序，定位长期占用 CPU 的活跃 SQL；

                                   查看dbe_perf.statements，按cpu_time排序，找出 CPU 消耗 Top SQL（如聚合 / 排序操作）。

             验证与优化：

                                   对 Top SQL 执行EXPLAIN ANALYZE，检查是否存在全表扫描、排序下盘（Sort Spill），通过添加索引、调大work_mem减少 CPU 消耗；

                                   若 CPU 核数不足，考虑扩容节点或调整业务并发度。

问题 2：WDR 报告中 “Top 10 Events by Total Wait Time” 显示 “STATUS wait cmd” 等待事件总时长过高，如何分析并解决该问题？

答案：“STATUS wait cmd” 属于 STATUS 类等待事件，通常与 SQL 执行过程中命令等待（如 GTM 交互、连接池获取）相关，分析与解决步骤如下：

             细化等待事件信息：

                                   查看 WDR 报告 Detail→Wait Events 模块，获取该事件的Waits（等待次数）、Avg Wait Time（平均等待时间）、Max Wait Time（最大等待时间）；

                                   若Avg Wait Time>1000us 且Waits次数多，说明存在频繁的命令等待，需进一步定位等待场景。

             关联会话与 SQL：

                                   结合dbe_perf.session_stat_activity（快照时段数据），筛选wait_event='wait cmd'的会话，获取对应的query（执行 SQL）；

                                   若 SQL 涉及 GTM 操作（如事务提交、获取快照），检查dbe_perf.wait_events中gtm commit trans/gtm get snapshot事件的等待时长，可能是 GTM 节点负载过高；

                                   若 SQL 涉及连接池操作，查看dbe_perf.global_pooler_status，检查wait pooler get conn事件，可能是连接池容量不足。

             针对性解决：

                                   若 GTM 负载高：切换为 GTM-Lite 模式（减少中心节点负载），或扩容 GTM 节点；

                                   若连接池不足：调大pooler_max_connections（连接池最大连接数），或优化应用连接复用（如增加连接池超时时间）；

                                   若 SQL 本身耗时久：对 SQL 进行优化（如添加索引、简化逻辑），减少命令执行时长。

问题 3：GaussDB 混合负载场景下出现数据倾斜（某 DN 数据量是其他节点的 2 倍），如何通过 SQL 优化手段解决？

答案：混合负载场景的数据倾斜分为 “存储层倾斜”（分布列不当）和 “计算层倾斜”（重分布导致），需分场景优化：

1. 存储层倾斜（分布列选择不合理）

             诊断：
执行select table_skewness('表名');，若某 DN 数据占比 > 平均占比 10%（如 18 个 DN 平均 5.5%，某 DN 占 8%），判定为存储倾斜。

             解决：

                                   重新选择分布列：遵循三大原则 ——①选择离散值多的列（如用户 ID，避免性别）；②选择关联 / 聚合字段（如订单表按order_id，减少 Join 重分布）；③避免常量约束列（如状态列，易集中）；

                                   示例：原表按inv_date_sk（日期，离散度低）分布，改为按inv_item_sk（商品 ID，离散度高），执行ALTER TABLE inventory DISTRIBUTE BY HASH(inv_item_sk);，倾斜率从 8% 降至 5.6%。

2. 计算层倾斜（Join/GROUP BY 非分布列）

             诊断：
执行EXPLAIN PERFORMANCE，查看各 DN 执行时间，若某 DN 执行时间是其他节点的 3 倍以上（如某 DN 120s，其他 50s），判定为计算倾斜。

             解决：

                                   启用 RLBT（Runtime Load Balance Technology）：通过ANALYZE更新统计信息，系统自动识别倾斜 Key，非倾斜数据按 HASH 分布，倾斜数据按 RoundRobin 均匀分配；

                                   手工干预：通过 Plan Hint 指定倾斜列，如/*+ skew(inventory (inv_item_sk) (10000) */（指定inventory表inv_item_sk=10000为倾斜值）；

                                   调整连接顺序：通过/*+ leading(t1 t2) */强制小表先连接，减少倾斜数据量；若使用 HashJoin，确保小表作为构建表（减少哈希表大小）。

             验证：
优化后重新执行table_skewness（存储层）和EXPLAIN PERFORMANCE（计算层），确认各 DN 数据量差异 < 5%、执行时间差异 < 20%，倾斜问题解决。