看执行计划估数不准→确认统计缺失→analyze 收集→复测计划恢复。

活动专区

活动公告

上车！GBase 8a开发者联盟发车了 技术福利、人脉资源全都有！

认证培训专区

认证培训资料

GBase 8s GDCA 认证培训课前准备

GBase 8a

其他

物化视图报错：references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them

01-GBase 8s 事务型数据库 安装与卸载

GBase 8s

适配迁移

[GBase 8s 教程]GBase 8s 常用函数、表达式



# GBase 8c 统计信息缺失导致执行计划异常的排查记录

同一条查询在小表阶段很快，数据量涨上来以后突然变慢，很多人第一反应是加索引、改 SQL 或扩大内存。这个方向不一定错，但在 GBase 8c 里，先看统计信息往往更省力。优化器生成执行计划时需要估算行数、选择率和代价，如果统计信息过旧或缺失，即使 SQL 本身没有变化，执行计划也可能选错。

统计信息问题的麻烦在于它不一定报错。SQL 能正常执行，只是 Join 顺序不合理、索引没用上、扫描行数估算偏得离谱。业务侧看到的是慢，数据库侧没有明显异常。排查时如果只盯等待事件或资源使用，很容易忽略最基础的 ANALYZE。

## 估算行数偏差是一个很强的信号

执行计划里最值得先看的，不只是有没有走索引，而是估算行数和真实行数是否差很多。如果估算几百行，实际扫几千万行，后续 Join 方法、内存分配、并行策略都会被带偏。GBase 8c 支持使用 EXPLAIN 查看执行计划，例行维护里也明确提到可以使用 ANALYZE 收集统计信息，使用 VACUUM 回收空间并更新统计信息。

```sql
EXPLAIN SELECT c.cust_id,
               SUM(o.pay_amt) AS pay_amt
          FROM dwd_order o
          JOIN dim_customer c
            ON o.cust_id = c.cust_id
         WHERE o.order_day &gt;= DATE '2026-05-01'
           AND o.order_day &lt;  DATE '2026-06-01'
           AND c.status = 'A'
         GROUP BY c.cust_id;
```

如果执行计划显示某个过滤条件命中很少，但实际结果很多，或者计划里使用了明显不合理的 Join 顺序，就要怀疑统计信息。尤其是刚导入大量数据、刚做过批量更新、刚清理历史分区之后，统计信息很容易跟不上。

| 现象 | 可能原因 | 优先动作 |
|---|---|---|
| 估算行数和实际差很多 | 统计信息旧或缺失 | ANALYZE 相关表 |
| 索引突然不被选择 | 选择率估算变化 | 查统计信息和数据分布 |
| Join 顺序异常 | 大小表判断错误 | 更新统计信息后重看计划 |
| 大量临时文件 | Hash/Sort 估算不足 | 结合 work_mem 和统计信息看 |
| 分区表只查少数分区仍慢 | 分区统计不准 | 对分区或父表维护统计 |

## 数据变更后要主动收集，不要等慢了再补

统计信息不会自动理解业务已经完成一次大规模导入。比如日表每天凌晨导入上千万行，随后立刻跑报表。如果导入后没有 ANALYZE，报表查询可能还拿昨天的统计信息做计划。对于数据仓库类场景，这种问题很常见。

一个实用的做法是把统计信息收集放进 ETL 流程，而不是等 DBA 发现慢 SQL 再人工执行。

```sql
-- 数据导入完成后，对关键表收集统计信息
ANALYZE dwd_order;
ANALYZE dim_customer;

-- 如果只更新了某些宽表，也可以优先维护本次涉及的核心表
ANALYZE ads_order_month;
```

如果是分区表，维护策略要更细。新分区导入后至少要保证新分区相关统计信息可用；历史分区没有变化，不一定每次全表维护。否则维护时间本身也会成为夜间窗口压力。

| 表类型 | 建议策略 | 注意点 |
|---|---|---|
| 日增事实表 | 每次导入后 ANALYZE | 放在报表前 |
| 小维表 | 变更后 ANALYZE | 不需要过度频繁 |
| 分区大表 | 新分区或变更分区维护 | 避免全表维护拖窗口 |
| 临时中间表 | 大量写入后再查询前维护 | 防止后续 Join 估算错误 |
| 高频更新表 | 定期维护 | 结合膨胀和 VACUUM 看 |

## VACUUM 和 ANALYZE 目标不同

很多人把 VACUUM 和 ANALYZE 混在一起说，但两者关注点不同。ANALYZE 主要收集统计信息，帮助优化器；VACUUM 更关注空间回收和对象维护，同时也可能更新统计信息。现场处理时要知道自己想解决什么问题。

如果问题是执行计划估算不准，优先看 ANALYZE。如果问题是大量更新删除后空间膨胀、旧版本数据影响维护，就要考虑 VACUUM。不要因为查询慢就机械执行重维护，也不要因为刚 VACUUM 过就认为统计信息一定满足当前查询需要。

```sql
-- 收集统计信息
ANALYZE schema_name.table_name;

-- 回收空间并维护对象，具体窗口要谨慎安排
VACUUM schema_name.table_name;
```

生产环境执行 VACUUM 前要看表大小、业务窗口、锁影响和资源占用。维护命令本身也会消耗资源，不适合在业务高峰随手执行。

## 计划变化要留前后对比

优化执行计划最怕“改完好了，但不知道为什么”。统计信息维护前后，建议保留 EXPLAIN 输出、执行耗时、扫描行数、返回行数和表数据量。这样后续如果再次变慢，可以判断是同类问题复发，还是数据分布发生了新变化。

```text
维护前：dwd_order 估算 1200 行，实际月数据约 1800 万行，计划选择嵌套循环
处理动作：ANALYZE dwd_order; ANALYZE dim_customer;
维护后：估算提升到千万级，计划改为 Hash Join，执行时间从 28 分钟降到 4 分钟
结论：主因是事实表统计信息过旧，不是索引缺失
```

这种记录比“执行 ANALYZE 后恢复”更有价值。它能帮助团队理解为什么要把 ANALYZE 放进 ETL，而不是把它当成 DBA 临时救火命令。

## 临时表和中间表也可能需要统计信息

复杂报表经常先生成中间表，再继续和其他表关联。如果中间表数据量很大，而生成后没有统计信息，后续查询同样可能计划异常。很多人只维护正式表，忘了临时或阶段表也会参与优化。

```sql
CREATE TEMP TABLE tmp_order_active AS
SELECT cust_id, SUM(pay_amt) AS pay_amt
  FROM dwd_order
 WHERE order_day &gt;= DATE '2026-05-01'
   AND order_day &lt;  DATE '2026-06-01'
 GROUP BY cust_id;

ANALYZE tmp_order_active;

SELECT t.cust_id, t.pay_amt, c.level_name
  FROM tmp_order_active t
  JOIN dim_customer c
    ON t.cust_id = c.cust_id;
```

这一步在数据量很小时可能看不出差异，但在百万级、千万级中间结果上，统计信息会明显影响后续 Join 选择。

## 常见坑

| 常见坑 | 表现 | 建议 |
|---|---|---|
| 导入后直接跑报表 | 计划沿用旧估算 | ETL 后加 ANALYZE |
| 只看有没有索引 | 忽略选择率估算 | 先看估算行数偏差 |
| 维护全库统计 | 窗口被维护任务占满 | 按关键表、变更表维护 |
| 忽略中间表 | 后续 Join 计划异常 | 大中间表生成后 ANALYZE |
| VACUUM 随手执行 | 高峰期资源波动 | 安排维护窗口 |
| 没留计划前后对比 | 问题复发无法复盘 | 保存 EXPLAIN 和耗时 |

## 一套更稳的维护流程

```text
1. 数据导入或批量变更完成
2. 记录本次变更表、分区、数据量
3. 对关键事实表、维表、中间表执行 ANALYZE
4. 对高频更新删除表按窗口执行 VACUUM
5. 核心报表跑前抽查 EXPLAIN
6. 慢 SQL 出现时优先比较估算行数和实际数据量
7. 将维护动作写入调度，不依赖人工记忆
```

这套流程不复杂，难点在于形成习惯。统计信息维护本质上是数据变更流程的一部分，而不是查询变慢后的补丁。

## 结尾总结

GBase 8c 执行计划异常时，不要只盯索引和 SQL 写法。统计信息过旧、缺失或与当前数据分布不匹配，是很多慢查询的根因。ANALYZE 的作用是让优化器重新认识数据，VACUUM 则更多承担空间回收和对象维护，两者要按目标使用。

生产环境里更推荐把统计信息维护前置：数据导入后、分区变更后、大批量更新后、关键中间表生成后，都应该考虑是否需要 ANALYZE。排查慢 SQL 时，先看估算行数偏差，再决定是否改 SQL 或加索引。这样处理通常比直接堆索引更稳，也更容易复盘。

## 参考资料

```text
[1] GBase 8c 例行维护官方文档 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
[2] GBase 社区优质文章区 https://www.gbase.cn/community/section/11
```

```

```



GBase 8c

GBase 8c 统计信息缺失导致执行计划异常的排查记录

GBase 8c 统计信息缺失导致执行计划异常的排查记录

评论

热门帖子