GaussDB自动统计信息收集策略【华为根技术】

GaussDB 的自动统计信息收集策略设计得比较精细，它并不是简单的定时任务，而是结合了​​实时监测​​和​​阈值触发​​的机制，目的是在保证统计信息准确性的同时，尽量减少对系统资源的消耗。

一、自动统计信息收集策略概览

GaussDB 采用了三种统计信息收集方式协同工作：

这三种方式相辅相成，共同构成了 GaussDB 的自动统计信息收集体系。

 二、触发条件与监测机制

1. ​​触发条件​​：

   • 自动收集主要在​​查询开始时​​被触发。其核心条件是：

     • ​​无统计信息​​：表从未被分析过。

     • ​​数据变化超过阈值​​：自上次统计信息收集后，表的修改量（INSERT, UPDATE, DELETE）达到设定的阈值。默认阈值公式为：​​50 + 表大小 * 10%​​。这意味着小表只要有几十条修改就可能触发，而大表需要累积足够的变化量。

2. ​​监测机制​​：

   • 监测并非真正的“实时”轮询，而是由 ​​autovacuum后台线程​​定期（可配置间隔）扫描所有表，检查其元数据中记录的逻辑修改计数（pg_stat_get_tuples_changed）。

   • 当查询执行时，优化器会​​实时​​检查该表在内存中的修改计数是否超过阈值。如果超过，且计划使用 Stream 算子（多数分布式查询会使用），则会触发轻量的​​前台动态采样​​（Autoanalyze）。

 三、表结构变化 (DDL) 的处理

​对于大多数 DDL 操作，GaussDB 会将其记录为一个​​巨大的修改计数​​，从而确保能立即触发统计信息收集。这些操作包括：

• TRUNCATE TABLE

• TRUNCATE / EXCHANGE / DROP PARTITION

• ALTER COLUMN TYPE

• ALTER DISTRIBUTE

这是因为协调节点（CN）无法准确获取数据节点（DN）上执行 DDL 后的具体数据变化量，因此采用一种保守但安全的策略，直接标记为需要分析。

 四、分区表统计信息管理

GaussDB 对分区表统计信息的高级管理功能提及较少，但可以基于其原理推断：

• ​​分区级别统计信息拷贝​​：搜索到的资料未明确提及支持直接将一个分区的统计信息拷贝到另一个分区。通常，每个分区的统计信息是独立收集和存储的。

• ​​分区级别统计信息锁定​​：资料中提到了表级统计信息冻结（frozen_stats=true），但未明确说明是否支持分区级别。理论上，可以通过对特定分区子表设置该属性来实现类似效果，但建议在实际使用前进行测试验证。

五、主要相关参数

这些参数支持全局设置，也支持通过 ALTER TABLE ... SET (parameter_name = value)为单个表设置特定值。

六、数据变化与收集的敏感性

• ​​新建表并插入1行​​：新表没有统计信息，​​下次查询该表时就会触发动态采样​​。因此，插入后立即查询，通常会触发收集。

• ​​凌晨3点几百条，早上9点上百万条却未更新​​：这种​​统计信息严重滞后​​的情况通常由以下原因导致：

  1. ​​阈值设置不合理​​：对于急速膨胀的表，默认的 10%比例阈值可能过高。例如，表从 1000 行增长到 100 万行，需要增长 10万行（1000 * 0.1=100）才会触发。​​解决方案​​：对此类表设置更激进的表级阈值，例如 ALTER TABLE fast_growth_table SET (autovacuum_analyze_scale_factor = 0.01);（1%）。

  2. ​​后台线程繁忙或延迟​​：后台 autovacuum线程数量不足（autovacuum_max_workers）或轮询间隔（autovacuum_naptime）设置太长，导致来不及处理。

  3. ​​长事务阻塞​​：一个长时间运行的事务可能持有表的锁，阻止了 autovacuum或 autoanalyze对其进行分析。

  4. ​​参数未开启或模式不对​​：确保 autoanalyze=on且 autoanalyze_mode='light'。

  5. ​​资源争用​​：系统负载极高，CPU、内存或IO资源不足，导致统计信息收集任务无法及时执行或排队过长。

 总结一下下哦

GaussDB 的自动统计信息收集是一个以​​查询触发为主、后台轮询为辅​​的混合机制。它通过​​实时监测数据变化并比对阈值​​来决定是否收集，力求在​​准确性和开销​​之间取得平衡。

• ​​保持默认开启​​：一般情况下，保持 autoanalyze和 autovacuum为 on，并采用 light模式。

• ​​关注特殊表​​：

  • 对于​​快速增长的表​​（如事实表），​​调低其表级触发比例​​（如 scale_factor=0.01）。

  • 对于​​数据分布不均匀​​或​​查询计划极其重要​​的表，可在数据加工完成后​​手动执行 ANALYZE​​ 以确保最优。

  • 考虑开启 enable_extrapolation_stats，让优化器在统计信息轻微过期时也能做出较好估算。

• ​​监控与诊断​​：

  • 查询 pg_stat_all_tables视图，关注 n_tup_ins， n_tup_upd， n_tup_del和 last_analyze时间，手动判断统计信息是否及时。

  • 如果遇到性能问题，检查执行计划，首先怀疑的就是统计信息是否准确。