本文主要记录GP统计信息缺失从发现到处理的步骤，最后发现gp_toolkit方案的查询结果好像不准确。
想看统计信息处理命令的直接看第三部分哦
一、发现统计信息缺失的表
GP的统计信息存储在pg_statistic系统表中，该表保存了每个数据表的最后一次analyze操作的结果（感兴趣的可以通过官方文档查看该表的字段信息）。但是这个系统表可读性比较差，我们可以通过pg_stats视图查看，这个视图我没在文档中找到，仅在pg_statistic的说明中提到了一下，感兴趣的可以用下面的命令查看下它的结构：
\d+ pg_catalog.pg_stats;
平时我们会比较关注哪些表缺失统计信息，在gp_toolkit方案中提供了如下方法查询：
SELECT * from gp_toolkit.gp_stats_missing;
因为刚接手GP，出于好奇用这个命令查了下，结果发现大量表缺少统计信息，大约占总表数的35%。
二、问题排查
第一反应就觉得不对劲，怎么会这么多，然后就去查集群统计信息收集的配置：
gp_autostats_mode=on_no_stats
该配置指定使用触发自动统计信息收集的模式。配置on_no_stats 选项可以触发对任何没有统计信息的表上的 CREATE TABLE AS SELECT，INSERT，或 COPY 操作的统计信息收集。配置详解见gp_autostats_mode
看了解释更疑惑了，不应该有这么多表没有统计信息啊。思来想去只有一种可能能够说服自己，就是对表做DDL操作会导致统计信息失效，而gp_toolkit将统计信息失效的表也归纳为统计信息缺失。
三、处理方法
我们知道GP统计信息分析有三种方式：
1、手动：用户直接在客户端运行analyze命令
2、手动：用户在数据库外部（服务器上）运行analyzedb管理工具
3、自动（参数配置）：当在没有统计信息的表上执行DML操作或者一个DML操作修改的行数超过指定阈值时，会触发自动分析操作
下面列出分析统计信息相关的命令：
检查表上缺失的统计信息。
SELECT smischema || '.' || smitable FROM gp_toolkit.gp_stats_missing;
更新某张表统计信息
analyzedb -d 数据库名 -t schema名.表名
更新多张表统计信息
psql -d 数据库名 -tAXc "select smischema || '.' || smitable from gp_toolkit.gp_stats_missing | xargs -P 5 -i analyzedb -d acrmdb -a -t {}"
更新全库统计信息
analyzedb -d 数据库名 -a -p 10
备份统计信息
gpsd -h IP地址 -p 端口 -U 用户 -s 数据库名
四、实验
知道了处理方法，那么就开始进入实验环节。
我在容灾集群的两个schema做了实验，结果如下：
| schema | 统计信息缺失的表数（分析前） | 统计信息缺失的表数（分析前后） | 下降比例 |
|---|---|---|---|
| schema1 | 105 | 63 | 40% |
| schema2 | 1561 | 843 | 46% |
看到这结果我蒙了。然后我就分析schema2中这843个统计信息缺失的表，去pg_stats中查到，这843张表里有241张表其实是有统计信息的。
这里就产生了两个问题：
问题一：为什么analyzedb执行后，还有统计信息缺失的表？
问题二：为什么分析后gp_toolkit.gp_stats_missing中显示有843张表缺失统计信息，而在pg_stats中查出，这843张表里有241张表是可以查到统计信息的？
有知道的大佬还请帮忙评论解释下，现在只能等公司的维保采购完成后问厂商了。。。
