GBase 8c 做性能优化时，我更先看统计信息、执行计划和资源池，而不是一上来就改 SQL

我最近看 GBase 8c 资料时有个很直接的感受：这类库做调优，和传统单机事务库的手法差别还是挺大的。GBase 8c 本身支持单机、主备和分布式形态，也支持行存、列存、内存、向量、时序等多种存储模式；在分布式场景下，它还强调强一致事务、MVCC、并行处理和弹性扩展能力。也正因为这样，线上一条查询变慢，问题未必只在 SQL 写法本身，很多时候是统计信息老了、执行计划漂了、资源分配不均，或者表的存储与分布方式从一开始就和业务路径不匹配。

从落地角度看，GBase 8c 这类库更适合按"统计信息是否可信 → 执行计划是否走偏 → 存储与分布是否贴合业务 → 会话和资源是否被挤压"这条线去排。这样做的好处是，不会一看到慢查询就开始堆索引、改 Hint，最后把问题越修越碎。官方资料里也反复强调，优化器的决策依赖统计信息，执行计划是理解查询行为的核心工具，而资源负载管理又会直接影响不同业务在 CPU、内存、IO 上的竞争关系。

一、先把 GBase 8c 的调优视角摆正：它不是只看单条 SQL 的数据库

我自己理解下来，GBase 8c 最容易被低估的一点，就是它不是一个单一形态的数据库。它既支持行存，也支持列存，还能在分布式场景下做并发处理和弹性扩展。对业务来说，这意味着两个结论：

第一，表结构和存储选型会直接影响后面所有 SQL 的上限 。

第二，执行计划的好坏，不只是"有没有索引"，而是优化器怎么看待代价、数据分布和可用资源。

这个点我个人比较在意。因为线上很多性能问题，表面看是查询慢，实际上根因在更早的地方。比如：

OLTP 明细表本来更适合行存，却被当成分析表去建；
小维表明明适合复制策略，却和大表一起走了不必要的数据分布；
统计信息长期不更新，优化器还在拿旧数据估算行数；
高峰期一堆查询共享资源池，排序和 Hash 操作挤在一起落盘。

所以我更倾向于把 GBase 8c 的性能问题分成三类来看：

|-------|----------------------|-------------------------------------|
| 类型 | 典型表现 | 更适合先看什么 |
| 模型层问题 | 从上线开始就不稳，扩容后收益也不明显 | 存储模式、分布策略、索引设计 |
| 优化器问题 | 同样 SQL，计划忽然变化，耗时抖动明显 | 统计信息、EXPLAIN、Hint 是否被误用 |
| 资源层问题 | 高峰期整体变慢，单条 SQL 未必最差 | work_mem、shared_buffers、资源池、Cgroups |

这个拆法不是标准答案，但在现场排查时通常很省时间。

二、统计信息不准，后面的执行计划分析基本都会失真

我最近看资料时发现，GBase 8c 对统计信息这件事说得非常明确：优化器要依赖 ANALYZE 收集到的统计信息，这些信息会存到 pg_class、pg_statistic 等系统目录里；如果统计信息没有收集，或者已经明显过时，优化器的行数估算和代价估算就会偏掉，最后生成不合适的计划。社区文章和教程里都把这个点放得很靠前。

这一点放到实际运维里，最常见的现象就是：

明明昨天走索引，今天开始全表扫描；
明明业务量只涨了一点，排序和 Join 的耗时却翻倍；
明明 SQL 没改，执行计划却换了路径。

这时候我一般不会先怀疑数据库"抽风"，而是先确认统计信息有没有更新，尤其是这些场景：

大批量导入、删除、归档之后；
分区刚切换完；
热点列的数据分布发生变化；
新表上线后快速放量。

GBase 8c 支持直接执行 ANALYZE，也支持结合自动维护机制处理统计信息更新。官方资料提到，ANALYZE 可以对单表、整库，甚至特定列或多列组合做统计；而 autovacuum、autovacuum_mode 等参数则可以控制自动清理和分析行为。

我平时更常用的几种方式大概是这样：

复制代码

-- 更新单表统计信息
ANALYZE sales_order;

-- 更新整库统计信息
ANALYZE;

-- 针对列做分析
ANALYZE sales_order (customer_id, order_date);

-- 查看执行计划前，先确认统计信息已经补齐
EXPLAIN ANALYZE
SELECT customer_id, sum(pay_amount)
FROM sales_order
WHERE order_date >= date '2026-03-01'
GROUP BY customer_id;

如果是分区表，官方教程也提到更新时会同时处理分区表的继承统计信息以及各个分区的统计信息。这个细节挺重要，因为很多人只盯总表，不盯分区，最后统计信息其实还是偏的。

三、在 GBase 8c 里看执行计划，我更关注 rows 估算偏差和算子组合，而不只是"有没有走索引"

GBase 8c 文档对执行计划说明得比较完整。EXPLAIN 可以带 ANALYZE、VERBOSE、COSTS、CPU、BUFFERS、TIMING、FORMAT 等选项；其中 EXPLAIN ANALYZE 会真实执行 SQL，并反馈实际时间、行数等信息。官方社区也强调，执行计划本质上是在描述优化器如何把 SQL 转成物理操作步骤，包括扫描方式、Join 方式、预估行数、成本和缓冲区使用情况。

真正落到现场排查时，我一般会先看下面几组信息：

rows 预估和实际返回差多少；
是 Seq Scan、Index Scan 还是 Index Only Scan；
Join 用的是 Hash Join、Nested Loop 还是 Merge Join；
排序和聚合有没有明显吃内存，或者开始写磁盘；
Buffers 里 shared hit/read 的比例怎么样。

一个很典型的例子是：

如果优化器估算某个条件只会返回几百行，结果实际返回几十万行，那么它可能会倾向 Nested Loop，但真实执行时会非常痛苦。这类问题表面看像 Join 方式选错，实际上常常是统计信息没有反映真实分布。

示例我一般会这样看：

复制代码

EXPLAIN (ANALYZE, VERBOSE, COSTS, BUFFERS, TIMING)
SELECT o.customer_id, sum(o.pay_amount)
FROM sales_order o
JOIN dim_customer c
  ON o.customer_id = c.customer_id
WHERE o.order_date >= date '2026-03-01'
  AND c.customer_level = 'VIP'
GROUP BY o.customer_id;

如果计划里已经出现下面这些信号，我会优先处理：

|-----------------------------|-----------------------|-----------------|
| 信号 | 常见原因 | 常见动作 |
| Seq Scan 出现在大表高频过滤列上 | 没索引或估算认为走索引不划算 | 先核实统计信息，再评估索引 |
| Hash Join 代价高且溢写明显 | work_mem 偏小，或输入结果过大 | 缩小输入集、增大会话内存 |
| Nested Loop 被大结果集驱动 | rows 估算严重偏差 | 先修统计信息，再看 Hint |
| Sort /GroupAggregate 很重 | 列裁剪不够，结果集放大 | 调整 SQL 形态、减少无效列 |

这里最容易犯的错，就是一看到执行计划不满意，就马上上 Hint。这个做法不是不能用，但不该当第一手段。

四、Hint 可以救火，但我更把它当"最后的定点干预"

GBase 8c 支持在 SQL 前通过 /*+ ... */ 方式加 Plan Hint，社区里列出的类型包括 Leading、NestLoop、HashJoin、MergeJoin、IndexScan、SeqScan、IndexOnlyScan 以及 Rows 等。也就是说，你可以直接对 Join 顺序、Join 方式、扫描方式，甚至结果集行数估算给优化器"下指令"。

但我自己理解下来，Hint 只适合两类场景：

短期救火：业务窗口很急，先把错误计划压住；
已经确认统计信息、索引、SQL 形态都没有明显问题，只是优化器在特定场景下仍然选偏。

示例：

复制代码

SELECT /*+ Leading((c o)) HashJoin(c o) */
       o.customer_id, sum(o.pay_amount)
FROM dim_customer c
JOIN sales_order o
  ON c.customer_id = o.customer_id
WHERE c.customer_level = 'VIP'
  AND o.order_date >= date '2026-03-01'
GROUP BY o.customer_id;

Hint 的问题在于，它绕过了优化器本来的成本判断。一旦数据量、分布、业务条件发生变化，昨天有效的 Hint，明天就可能变成新的性能包袱。社区文章也明确提醒，Hint 是双刃剑，要持续验证，而不是一加完就当永久方案。

所以我的顺序通常是：

先修统计信息，再看计划；

计划确实稳定走偏，再考虑 Hint；

Hint 生效后，还要回头补模型和参数，不要让它长期替代优化器。

五、GBase 8c 的参数调优，我更关注 work_mem、shared_buffers 和语句跟踪，而不是一堆参数一起改

社区和文档里都提到，work_mem 会影响排序、Hash Join 等操作能否在内存中完成，shared_buffers 关系到共享缓存能力，而 enable_hashjoin、enable_indexscan 这类开关则会影响优化器可选策略。换句话说，在 GBase 8c 里，参数不是"调大就更快"，而是要看当前 SQL 的算子特点和整体负载状态。

我更常见到的两个误区是：

1）`work_mem` 一口气拉太大

单条语句里的排序、哈希、聚合节点可能不止一个，多个并发会话叠加后，内存消耗会迅速放大。单条 SQL 看着没问题，高峰期整机却容易抖。

2）只会看数据库参数，不看慢 SQL 跟踪

官方维护文档里提到，语句跟踪依赖 track_stmt_stat_level，其中第一部分控制全量 SQL，第二部分控制慢 SQL；当慢 SQL 跟踪开启且执行时间超过 log_min_duration_statement 时，会被记录下来。再结合 enable_stmt_track 和 dbe_perf.get_global_slow_sql_by_timestamp() 之类的接口，就能把"感觉慢"变成"有时间窗口和证据的慢"。

我一般会这样做一个最小排查闭环：

复制代码

-- 开启语句跟踪前先确认参数
SHOW track_stmt_stat_level;
SHOW enable_stmt_track;
SHOW log_min_duration_statement;

-- 查指定时间段慢 SQL
SELECT *
FROM dbe_perf.get_global_slow_sql_by_timestamp(
  '2026-03-24 09:00:00',
  '2026-03-24 09:10:00'
);

如果配合应用侧接口耗时一起看，定位会快很多。因为你能很清楚地知道，到底是数据库内部跑慢了，还是连接池、网络、应用逻辑把时间吃掉了。

六、GBase 8c 的资源治理不能只停留在数据库参数层，资源池和 Cgroups 才是高峰期稳定性的关键

这个点我最近整理下来觉得特别值。GBase 8c 官方开发者指南里明确写到，资源负载管理的核心是资源池，而资源池又建立在 Linux Cgroups 之上。Cgroups 本身用于限制、记录和隔离进程组使用的 CPU、内存、IO 等物理资源；gs_cgroup 工具则负责为数据库用户创建和维护对应配置。也就是说，GBase 8c 并不是只靠数据库内部参数做资源治理，它是把数据库和操作系统资源控制打通了。

从实际场景看，这个能力特别适合下面几类环境：

白天在线交易 + 晚上批量跑数共存；
报表查询、ETL、审计抽取都在同一套集群里；
某些租户或业务组容易在峰值时把 CPU 吃穿。

我更倾向于这样理解资源池：

|------------|----------------------|---------------|
| 场景 | 不做资源隔离时 | 做资源池/控制组后 |
| 大报表和在线查询共存 | 报表把 CPU、IO 抢满，在线请求抖动 | 给报表单独池子，限制上限 |
| 批量导入时间不可控 | 导入和查询互相拖慢 | 将导入作业限流到独立资源组 |
| 多业务共库 | 某一类 SQL 抢占内存 | 用资源池做业务分层 |

这个能力不是写一条 SQL 就能立刻见效的那种优化，但在高并发、混合负载场景下，它往往比"单条 SQL 再快一点"更重要。因为线上真正难受的，常常不是某一条查询跑 8 秒，而是所有查询都在高峰期一起抖。

七、存储方式和分布方式如果一开始没选对，后面再怎么微调都容易吃力

前面说到 GBase 8c 支持多种存储模式，这不是"产品介绍"层面的卖点，到了实际设计阶段会直接变成性能差异。社区资料提到，GBase 8c 支持行存 orientation=row、列存 orientation=column，还支持 ustore 等不同存储类型；同时在分布式表上支持 DISTRIBUTE BY hash(...) 和 DISTRIBUTE BY replication 等策略。

我自己更倾向于这样落地：

频繁点查、更新、事务路径短的核心表，优先考虑行存；
典型分析报表、聚合扫描多的表，更适合列存；
小表、维表、字典表，在分布式场景下优先考虑复制；
大事实表，根据 Join 主键或高频访问维度设计 Hash 分布。

一个更贴近现场的示例大概是这样：

复制代码

-- 明细交易表：偏事务访问，行存
CREATE TABLE txn_order (
    order_id      bigint,
    customer_id   bigint,
    order_time    timestamp,
    order_status  varchar(20),
    pay_amount    numeric(18,2)
) WITH (orientation=row)
DISTRIBUTE BY hash(order_id);

-- 汇总分析表：偏统计访问，列存
CREATE TABLE rpt_order_day (
    stat_date      date,
    customer_id    bigint,
    city_id        int,
    order_cnt      bigint,
    pay_amount_sum numeric(18,2)
) WITH (orientation=column)
DISTRIBUTE BY hash(customer_id);

-- 小维表：复制
CREATE TABLE dim_city (
    city_id    int,
    city_name  varchar(64),
    region_id  int
) DISTRIBUTE BY replication;

这个设计不一定放之四海而皆准，但它至少符合 GBase 8c 的一个核心特点：把事务访问、分析访问和分布式 Join 成本分开考虑。 如果一开始就把这些揉成一团，后面做参数调优往往只能缓解，不能根治。

八、我更常用的一套 GBase 8c 优化顺序

如果把前面的内容收成一套更实战的顺序，我通常会这么做：

1. 先确认问题是不是稳定复现

接口偶发超时，未必是数据库；先拿到业务时间窗口。

2. 拉慢 SQL 和系统视图

确认 track_stmt_stat_level、enable_stmt_track、log_min_duration_statement 设置是否合理，再从 dbe_perf 里把那段时间的慢 SQL 拉出来。

3. 看 EXPLAIN ANALYZE

重点盯 rows 估算误差、Join 类型、Sort/Hash 是否重、Buffers 是否异常。

4. 回头补统计信息

先排除优化器"看错地图"的情况，再谈更细的调优。

5. 再决定是改 SQL、补索引还是加 Hint

Hint 只适合定点干预，不适合替代模型设计。

6. 最后看资源层

高峰期问题，就别只盯单条 SQL，直接把资源池、Cgroups、会话内存和缓存一起看。

九、真正把 GBase 8c 用稳，我更看重的是"优化器可信、资源边界清楚、存储模型贴业务"

我自己理解下来，GBase 8c 这种数据库最怕的不是"没有高级功能"，而是功能很多，结果现场用法还是停留在传统单机库那一套：SQL 慢了就加索引，计划不对就上 Hint，高峰期抖了就改一个参数。这样做有时能救一时，但很难把系统长期跑稳。

真正更稳的做法，还是把几件事连起来看：

统计信息是不是持续可信；
执行计划是不是和真实数据分布一致；
行存、列存、复制表、Hash 分布有没有贴业务路径；
work_mem、shared_buffers 这类参数是不是和负载匹配；
资源池有没有把不同业务边界分清楚。

如果这几层都能压住，GBase 8c 的性能优化就不会只停留在"某条 SQL 快了 20%"这种局部改善，而会更接近生产环境真正需要的状态：高峰期不抖，计划不乱飘，资源不被少数查询拖穿。

复制代码

参考资料

[1] 技术白皮书 | GBASE南大通用
https://www.gbase.cn/docs/gbase-8c/%E6%8A%80%E6%9C%AF%E7%99%BD%E7%9A%AE%E4%B9%A6/%E6%8A%80%E6%9C%AF%E7%99%BD%E7%9A%AE%E4%B9%A6

[2] GBase 8c性能优化实战：从统计信息到执行计划调优全解析
https://www.gbase.cn/community/post/6735

[3] 南大通用GBase 8c 执行计划功能说明
https://www.gbase.cn/community/post/5593

[4] GBase 8c 教程（十七）更新规划期统计信息
https://www.gbase.cn/community/post/1852

[5] 例行维护 | GBASE南大通用
https://www.gbase.cn/docs/gbase-8c/02%20%E7%AE%A1%E7%90%86%E5%91%98%E6%8C%87%E5%8D%97/03%20%E8%BF%90%E7%BB%B4%E7%AE%A1%E7%90%86/%E4%BE%8B%E8%A1%8C%E7%BB%B4%E6%8A%A4

[6] 资源负载管理 | GBASE南大通用
https://www.gbase.cn/docs/gbase-8c/03%20%E5%BC%80%E5%8F%91%E8%80%85%E6%8C%87%E5%8D%97/%E8%B5%84%E6%BA%90%E8%B4%9F%E8%BD%BD%E7%AE%A1%E7%90%86

[7] gs_cgroup | GBASE南大通用
https://www.gbase.cn/docs/gbase-8c/04%20%E5%B7%A5%E5%85%B7%E5%8F%82%E8%80%83/02%20%E6%9C%8D%E5%8A%A1%E7%AB%AF%E5%B7%A5%E5%85%B7/gs_cgroup

[8] 南大通用GBase 8c行存储引擎下的语法概述
https://www.gbase.cn/community/post/4401

[9] GBase8c修改内存 - GBase 8c
https://www.gbase.cn/community/post/7834

GBase 8c 做性能优化时，我更先看统计信息、执行计划和资源池，而不是一上来就改 SQL

一、先把 GBase 8c 的调优视角摆正：它不是只看单条 SQL 的数据库

二、统计信息不准，后面的执行计划分析基本都会失真

三、在 GBase 8c 里看执行计划，我更关注 rows 估算偏差和算子组合，而不只是"有没有走索引"

四、Hint 可以救火，但我更把它当"最后的定点干预"

五、GBase 8c 的参数调优，我更关注 work_mem、shared_buffers 和语句跟踪，而不是一堆参数一起改

1）work_mem 一口气拉太大

2）只会看数据库参数，不看慢 SQL 跟踪

六、GBase 8c 的资源治理不能只停留在数据库参数层，资源池和 Cgroups 才是高峰期稳定性的关键

七、存储方式和分布方式如果一开始没选对，后面再怎么微调都容易吃力

八、我更常用的一套 GBase 8c 优化顺序

1. 先确认问题是不是稳定复现

2. 拉慢 SQL 和系统视图

3. 看 EXPLAIN ANALYZE

4. 回头补统计信息

5. 再决定是改 SQL、补索引还是加 Hint

6. 最后看资源层

九、真正把 GBase 8c 用稳，我更看重的是"优化器可信、资源边界清楚、存储模型贴业务"

1）`work_mem` 一口气拉太大