本文主要記錄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張表是可以查到統計信息的？
有知道的大佬還請幫忙評論解釋下，現在只能等公司的維保採購完成後問廠商了。。。
