表索引诊断

诊断项

描述

建议

每个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小于1天的表

表数据TTL可用于管理数据的生命周期，数据会在超过TTL后被清除，但TTL不会严格保证数据删除的时间，而是会在过期后的某个时间删除数据。当TTL设置的时间越短，数据删除的时间也会越快。因此建议TTL不小于1天，否则可能会导致数据重复、数据被误删除等问题。详情请参见其他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;