診斷項

描述

建議

每個DB對應的表和View數量

展示當前實例，每個DB內的內部表、分區子表、外部表及View的總量。

建議對表數量較多的DB進行針對性治理。

每個TG對應的內表數量

展示每個Table Group的內部表數量（包括分區子表）。

• Hologres中，一個Table Group的內部表總數不建議超過1W，如果數量太多，會導致DDL執行變慢，且影響版本升級速度。建議使用Resharding功能對Table Group進行治理，以達到健康的狀態。詳情請參見Resharding。

• 不建議一張表設置一個Table Group，否則會導致Table Group數量過多，Worker資源無法有效分配。如果Table Group中只有一張表，建議對Table Group進行治理。

分區表數和存儲量

展示當前實例中分區表對應的分區子表和存儲量。

• 對于分區子表數量超過1W的分區表，建議使用冷熱分層的能力，將不常訪問的分區子表設為冷存存儲，以節約存儲成本。

• 對于存儲為0的分區表或分區數為0的表，建議刪除，否則空表也會占用一定的Meta空間。

存儲為0的表

展示當前熱存和冷存都為0的表。

建議及時清理存儲為0的表，以減少Meta內存的占用。

Segment格式的表

展示當前實例中所有采用Segment格式存儲的表。從V2.0版本開始，Hologres將不再支持Segment格式的表，需要手動將表轉換為壓縮算法更高效的ORC格式，在節約存儲成本的同時，也可能帶來性能的提升。如果不轉換為ORC格式，將無法升級實例到V2.0及以上版本。轉換操作請參見更改列存表的數據存儲格式。

無。

行存表

展示當前實例所有的行存表。

• 行存表僅用于基于主鍵的key-value查詢，不適用于OLAP查詢，會影響性能，請謹慎使用，詳情請參見行存。

• 可以通過慢Query日志查看最近一天某個行存表涉及的Query，如果發現有Engine Type是非SDK或非FixedQE的，則建議修改Query，或者修改表為列存表或行列共存表。

• 示例：

  --查看過去一天，某個表涉及到的query
  select usename,status,query_id,datname,command_tag,duration,message,query_start,query_end,query from hologres.hg_query_log where 
  query like '%<table_name>%'
  and query_start >= now() - interval '1 day';

行列共存表

展示當前實例所有的行列共存表。

行列共存表適合所有的應用場景，但是存儲會翻倍，請謹慎使用。詳情請參見行列共存。通過如下SQL查找某個行列共存表設計的Query。

--查看過去一天，某個表涉及到的query
select usename,status,query_id,datname,command_tag,duration,message,query_start,query_end,query from hologres.hg_query_log where 
query like '%<table_name>%'
and query_start >= now() - interval '1 day';

沒有設置主鍵（PK）的行存表

行存表僅用于基于主鍵的查詢，必須創建主鍵才會有效果。

• 為沒有設置PK的行存表設置PK。

• 將表改為列存形式。

行存表Distribution key和Clustering key不一致的表

必須將行存表的Distribution key和Clustering key設置為相同字段，否則會帶來額外的查詢開銷，降低查詢性能。

• 重新建表，確保行存表的Distribution key和Clustering key設置為相同字段。

• 改為列存表。

超過300列的列存表

列存表不建議超過300列，列越多，性能開銷越大。詳情請參見使用建議。

超過300列的行列共存表

行列共存表不建議超過300列，列越多，性能開銷越大。詳情請參見使用建議。

超過300列的行存表

行存表不建議超過300列，列越多，性能開銷越大。詳情請參見使用建議。

Distribution key超過3列的表

Distribution key用于決定數據的分布，尤其在Join場景中，合適的Distribution key可以實現Local Join，減少數據Shuffle，但Distribution key設置越多，使用場景越受限，建議控制在3列以內。詳情請參見分布鍵Distribution Key。

Clustering key超過3列的表

Clustering key可以實現數據在文件內排序，常用于Range和范圍過濾的場景，具有左匹配原則，不建議設置超過3列，否則命中索引的場景會受限。詳情請參見聚簇索引Clustering Key。

Segment key超過3列的表

Segment key用于劃分文件邊界，常用于時間戳等單調遞增或遞減的字段過濾查詢，具有左匹配原則，不建議設置超過3列，否則命中索引的場景會受限。詳情請參見Event Time Column（Segment Key）。

Clustering key列為nullable的表

Clustering key可以實現數據在文件內排序，常用于Range過濾，不建議將字段屬性設為Nullable，否則無法使用加速效果。詳情請參見聚簇索引Clustering Key。

重新建表，并將設置Clustering key的字段屬性設為NOT NULL。

Segment key列為nullable的表

Segment key用于劃分文件邊界，常用于時間戳等單調遞增或遞減的字段過濾查詢，不建議將字段屬性設為Nullable，否則無法使用加速效果。詳情請參見Event Time Column（Segment Key）。

重新建表，并將設置Segment key的字段屬性設為NOT NULL。

表數據TTL小于7天的表

表數據TTL可用于管理數據的生命周期，數據會在超過TTL后被清除，但TTL不會嚴格保證數據刪除的時間，而是會在過期后的某個時間刪除數據。當TTL設置的時間越短，數據刪除的時間也會越快。因此建議TTL不小于7天，否則可能會導致數據重復、數據被誤刪除等問題。詳情請參見SQL命令列表。

• 建議執行如下命令修改表數據的TTL，將其設為一個較大的值。

  --修改表數據的TTL為100年（永久）
  begin; 
  call set_table_property('<tablename>', 'time_to_live_in_seconds', '8640000');
  commit; 

• 對于分區表，建議使用動態分區管理分區子表的生命周期。

列出所有開了Binlog的表

開啟Binlog后，會有額外的存儲開銷，同時也建議行存表、行列共存表開啟Binlog，若列存表開啟Binlog，性能開銷較大。詳情請參見訂閱Hologres Binlog。

• 如果列存表開啟了Binlog，建議將表改為行存表或行列共存表。

• 對于非必要的表，可以關閉Binlog功能。

Binlog TTL大于7天的表

Hologres Binlog記錄了表的DML記錄，Binlog的TTL越長，保留的記錄越多，帶來的存儲開銷也越多，建議TTL保留在7天內。

對于Binlog TTL較長的表，使用如下語句將Binlog的TTL修改為一個較小的值。

--修改Binlog TTL為7天
begin; 
call set_table_property('<table_name>', 'binlog.ttl', '604800'); 
commit;