Hologres：表索引診斷

診斷項

描述

建議

每個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;