Greenplum统计信息常用命令及缺失处理方法

        本文主要记录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张表是可以查到统计信息的？

        有知道的大佬还请帮忙评论解释下，现在只能等公司的维保采购完成后问厂商了。。。