查看統計信息是否正確

通過查看執行計劃：

未及時同步統計信息導致生成較差的執行計劃，示例如下：

tmp1表的數據量為1000萬行，tmp表的數據量為1000行。 Hologres默認統計信息中的行數為1000行，通過執行explainSQL語句，如下展示結果所示，tmp1表的行數與實際的行數不符，該展示結果表明未及時更新統計信息。

Seq Scan on tmp1 (cost=0.00..5.01 rows=1000 width=1)

更新統計信息

analyze tmp;
analyze tmp1;

當發現explain返回結果中rows=1000，說明缺少統計信息。一般性能不好時，其原因通常是優化器缺少統計信息，需要通過及時更新統計信息，執行analyze <tablename>，可以簡單快捷優化查詢性能。

推薦更新統計信息的場景

推薦在以下情況下運行analyze <tablename>命令。

• 導入數據之后。

• 大量的INSERT、UPDATE以及DELETE操作之后。

• 內部表、外部表均需要ANALYZE。

• 分區表針對父表做ANALYZE。

• 如果遇到以下問題，您需要先執行analyze <tablename>，再運行導入任務，可以系統地優化效率。

  • 多表JOIN超出內存OOM。

    通常會產生Query executor exceeded total memory limitation xxxxx: yyyy bytes used報錯。

  • 導入效率較低。

    在Hologres查詢或導入數據時，效率較低，運行的任務長時間不結束。

更新統計信息

如上述查看統計信息中，參與Join的表如果未及時更新統計信息，可能會導致數據量大的表做了Hash表，從而導致Join效率變低。因此可以通過更新表的統計信息，提升SQL性能。

analyze <tablename>;

選擇合適的分布列（Distribution Key）

分布列（Distribution Key）用于將數據劃分到多個Shard，劃分均衡可以避免數據傾斜。多個相關的表設計為相同的Distribution Key，可以起到Local Join的加速效果。創建表時，您可以通過如下原則選擇合適的分布列：

• Distribution Key設置建議

  • 選擇Join查詢時的連接條件列作為分布列。

  • 選擇Group By頻繁的列作為分布列。

  • 選擇數據分布均勻離散的列作為分布列。

  • 更多關于Distribution Key的原理和使用詳情請參見分布鍵Distribution Key。

• 設置Distribution Key場景示例

  例如設置Distribution Key，表tmp和tmp1做Join，通過執行explain SQL語句看到執行計劃中有Redistribution Motion，說明數據有重分布，沒有Local Join，導致查詢效率比較低。您需要重新建表并同時設置Join Key為Distribution Key，避免多表連接時數據重分布帶來的額外開銷。重新建表后兩個表的DDL示例語句如下。

  begin;
  create table tmp(a int, b int, c int);
  call set_table_property('tmp', 'distribution_key', 'a');
  commit;
  
  begin;
  create table tmp1(a int, b int, c int);
  call set_table_property('tmp1', 'distribution_key', 'b');
  commit;
  
  -- 設置分布列為Join Key。
  select count(1) from tmp join tmp1 on tmp.a = tmp1.b ;

  通過重新設置表的Distribution Key，再次執行explain SQL語句，可以看到執行計劃中，紅框內的算子被優化掉了，數據按照相同的Hash Key分布于Shard中。因為數據分布相同，Motion算子被優化（上圖中紅框內的算子），表明數據不會重新分布，從而避免了冗余的網絡開銷。

使用Runtime Filter

從V2.0版本開始，Hologres開始支持Runtime Filter，通常應用在多表Join（至少2張表），尤其是大表Join小表的場景中，無需手動設置，優化器和執行引擎會在查詢時自動優化Join過程的過濾行為，使得掃描更少的數據量，從而降低IO開銷，以此提升Join的查詢性能，詳情請參見Runtime Filter。

優化Join Order算法

• 當SQL Join關系比較復雜時，或者Join的表多時，優化器（QO）消耗在連接關系最優選擇上的時間會更多，調整Join Order策略，在一定場景下會減少Query Optimization的耗時，設置優化器Join Order算法語法如下。

  set optimizer_join_order = '<value>'; 

• 參數說明

  參數	說明
  value	優化器Join Order算法，有如下幾種。 exhaustive2（V2.2及以上版本默認值）：升級優化的動態規劃算法。 exhaustive（早期版本默認值）：通過動態規劃算法進行Join Order轉換，會生成最優的執行計劃，但優化器開銷最高。 query：不進行Join Order轉換，按照SQL書寫的連接順序執行，優化器開銷最低。 greedy：通過貪心算法進行Join Order的探索，優化器開銷適中。

• 補充說明

  使用默認的exhaustive2算法可以全局探索最優的執行計劃，但對于很多表的Join（例如表數量大于10），優化耗時可能較高。使用query或者greedy算法可以減少優化器耗時，但無法生成最優的執行計劃。

優化Broadcast等Motion算子

目前Hologres包含四種Motion Node，分別對應四種數據重分布場景，如下表所示。

結合explain SQL語句執行結果您可以注意如下事項：

• 如果Motion算子耗時較高，則您可以重新設計分布列。

• 如果統計信息錯誤，導致生成Gather Motion或Broadcast Motion，則您可以通過analyze <tablename>命令將其修改為更高效的Redistribute Motion分布方式。

• Broadcast Motion只有在Shard數較少，且廣播表的數量較少的場景下有優勢。所以如果是小表Broadcast的場景，建議您將表的Shard數量減少（盡量保持Shard Count與Worker數量成比例關系），從而提高查詢效率。Shard Count詳情請參見Shard Count。

采用Fixed Plan

Fixed Plan適用于高吞吐場景，通過簡化的執行路徑，實現數倍性能和吞吐的提升，配置方式和使用方法請參考Fixed Plan加速SQL執行。

PQE算子改寫

Hologres底層有原生引擎HQE（Hologres Query Engine，向量引擎）和PQE（Postgres Query Engine，分布式Postgres引擎）等多個執行引擎，如果SQL語句中包含HQE不支持的算子，則系統會將該算子發送至PQE執行。此時查詢的性能未能足夠優化，需要修改相關查詢語句。

通過執行計劃（explain SQL）查詢，若執行計劃中出現External SQL（Postgres）則說明這部分的SQL是在PQE中執行的。

explain select * from tmp where a not in (select a from tmp1);

explain select * from tmp where not exists (select a from tmp1 where a = tmp.a);

select * from tmp where not exists (select a from tmp1 where a = tmp.a);

select name,unnest(string_to_array(age,',')) from demo;

select cast(substring(c1, 13, 2) as int) AS hour from t2;

select extract(hour from to_timestamp(c1, 'YYYYMMDD HH24:MI:SS')) from t2;

select regexp_replace(c1::text,'-','0') from t2;

select replace(c1::text,'-','') from t2;

select date_trunc('day',to_timestamp(c1, 'YYYYMMDD HH24:MI:SS')  at time zone 'utc') from t2

select date_trunc('day',to_timestamp(c1, 'YYYYMMDD HH24:MI:SS') ) from t2;

select cast(c1 as timestamp) from t2;

select to_timestamp(c1, 'yyyyMMdd hh24:mi:ss') from t2;

select c1::text from t2;

select to_char(c1, 'yyyyMMdd hh24:mi:ss') from t2;

避免模糊查詢

模糊查詢（Like操作）不會建立索引。

結果緩存對查詢的影響

Hologres會默認對相同的查詢或子查詢結果進行緩存，重復執行會命中緩存結果。您可以使用如下命令關閉緩存對性能測試的影響：

set hg_experimental_enable_result_cache = off;

OOM的優化手段

當實例計算內存不足時通常會出現OOM，常見的報錯如下。產生OOM的原因有多種，比如計算復雜、并發量高等，可以根據不同的原因進行針對性優化，從而減少OOM。詳情請參見OOM常見問題排查指南。

Total memory used by all existing queries exceeded memory limitation. 
memory usage for existing queries=(2031xxxx,184yy)(2021yyyy,85yy)(1021121xxxx,6yy)(2021xxx,18yy)(202xxxx,14yy); Used/Limit: xy1/xy2 quota/sum_quota: zz/100

Order By Limit場景優化

在Hologres V1.3之前版本，對Order By Limit場景不支持Merge Sort算子，生成執行計劃時，在最后輸出時還會做一次排序，導致性能相對較差。從1.3版本開始，引擎通過對Order By Limit場景優化，支持Merge Sort算子，實現多路歸并排序，無需再進行額外的排序，提升了查詢性能。

Count Distinct優化

• 改寫為APPROX_COUNT_DISTINCT

  Count Distinct是精確去重，需要把相同key的記錄shuffle到同一個節點去重，比較耗費資源。Hologres實現了擴展函數APPROX_COUNT_DISTINCT，采用HyperLogLog基數估計的方式進行非精確的COUNT DISTINCT計算，提升查詢性能。誤差率平均可以控制在0.1%-1%以內，可以根據業務情況適當改寫，詳情請參見APPROX_COUNT_DISTINCT。

• 使用UNIQ函數

  Hologres從 V1.3版本開始，支持UNIQ精確去重函數，在GROUP BY KEY的KEY基數較高時，比Count Distinct性能更好，更節省內存。當使用Count Distinct出現OOM時，可以使用UNIQ做替換，詳情請參見UNIQ。

• 設置合適的Distribution Key

  當有多個Count Distinct且是key是同一個并且數據離散均勻分布，建議將Count Distinct的key設置成Distribution Key，這樣相同的數據可以分布相同的Shard，避免數據Shuffle。

• Count Distinct優化

  Hologres從V2.1版本開始，針對Count Distinct場景做了非常多的性能優化（包括單個Count Distinct、多個Count Distinct、數據傾斜、SQL沒有Group By字段等場景），無需手動改寫成UNIQ，即可實現更好的性能。如果想要提升Count Distinct性能，建議您將Hologres實例升級至V2.1及以上版本。

Group By優化

Group By Key會導致數據在計算時按照分組列的Key重新分布數據，如果Group By耗時較高，您可以將Group By的列設置為分布列。

-- 數據如果按照a列的值進行分布，將減少數據運行時重分布，充分利用shard的并行計算能力。
select a, count(1) from t1 group by a; 

數據傾斜處理

-- hg_shard_id是每個表的內置隱藏列，描述對應行數據所在shard
select hg_shard_id, count(1) from t1 group by hg_shard_id;

With表達式優化（Beta）

Hologres兼容PostgreSQL ，支持CTE（Common Table Expression），常用在with遞歸查詢，其實現原理同PostgreSQL，都是基于Inlining展開的，所以當有多次使用CTE時會造成重復計算。在HologresV1.3版本中，可以通過如下GUC參數支持CTE Reuse（復用），這樣CTE只需計算一次而被多次引用，用以節省計算資源，提升查詢性能。若您的Hologres實例版本低于 V1.3，請升級實例。

set optimizer_cte_inlining=off;

• 示例

  create table cte_reuse_test_t
  (
      a integer not null,
      b text,
      primary key (a)
  );
  
  insert into cte_reuse_test_t values(1, 'a'),(2, 'b'), (3, 'c'), (4, 'b'), (5, 'c'), (6, ''), (7, null);
  
  
  set optimizer_cte_inlining=off;
  
  explain with c as (select b, max(a) as a from cte_reuse_test_t group by b)
  select a1.a,a2.a,a1.b, a2.b
  from c a1, c a2
  where a1.b = a2.b
  order by a1.b
  limit 100;
                                      

• 執行計劃對比

  • Hologres V1.3之前版本（V1.1）的執行計劃如下。

  • Hologres V1.3版本的執行計劃如下。

  從執行計劃的對比中可以看出Hologres V1.3之前版本會有多個AGG計算（HashAggregate），Hologres V1.3版本只需計算一次就被結果復用，提升了性能。

單階段Agg優化為多階段Agg

如果Agg算子耗時過高，您可以檢查是否沒有做Local Shard級別的預聚合。

set optimizer_force_multistage_agg = on;

選擇存儲類型

Hologres支持行存儲、列存儲和行列共存多種存儲模式，您可以根據業務場景選擇合適的存儲類型，如下表所示。

選擇數據類型

Hologres支持多種數據類型，您可以根據業務場景以及需求選擇合適的數據類型，原則如下：

• 盡量選用存儲空間小的類型。

  • 優先使用INT類型，而不是BIGINT類型。

  • 優先使用精確確定的DECIMAL/NUMERIC類型，明確數值精度（PRECISION，SCALE），且精度盡量小，減少使用FLOAT/DOUBLE PRECISION等非精確類型，避免統計匯總中的誤差。

  • GROUP BY的列不建議使用FLOAT/DOUBLE等非精確類型。

  • 優先使用TEXT，適用范圍更廣，當使用VARCHAR(N)和CHAR(N)，N的取值盡量小。

  • 日期類型使用TIMESTAMPTZ、DATE，避免使用TEXT。

• 關聯條件使用一致的數據類型。

  進行多表關聯時，不同列盡量使用相同的數據類型。避免Hologres將不同類型的列進行隱式類型轉換，造成額外的開銷。

• UNION或GROUP BY等操作避免使用FLOAT/DOUBLE等非精確類型。

  UNION或GROUP BY等操作暫不支持DOUBLE PRECISION和FLOAT數據類型，需要使用DECIMAL類型。

選擇主鍵

合理的設置主鍵能幫助優化器在某些場景下生成更好的執行計劃。例如，查詢為group by pk,a,b,c的場景。

但是在列存儲場景，主鍵的設置對于寫入數據的性能會有較大的影響。通常，不設置主鍵的寫入性能是設置主鍵的3倍。

選擇分區表

選擇索引

call set_table_property('tmp', 'clustering_key', 'a,b,c');
select * from tmp where a > 1 ;  --可以使用Cluster索引。
select * from tmp where a > 1 and c > 2 ;   --只有a可以使用Cluster索引。
select * from tmp where a > 1 and b > 2 ;  --a,b均可以使用Cluster索引。
select * from tmp where a > 1 and b > 2 and c > 3 ; --a,b,c均可以使用Cluster索引。
select * from tmp where b > 1 and c > 2 ;   --b,c均不能使用Cluster索引。

call set_table_property('tmp', 'bitmap_columns', 'a,b,c');
select * from tmp where a = 1 and b = 2 ;  -- 可以使用Bitmap索引。
select * from tmp where a = 1 or b = 2 ; -- 可以使用Bitmap索引。

查看是否使用Index

創建tmp表并指定索引字段，語句如下。

begin;
create table tmp(a int not null, b int not null, c int not null);
call set_table_property('tmp', 'clustering_key', 'a');
call set_table_property('tmp', 'segment_key', 'b');
call set_table_property('tmp', 'bitmap_columns', 'a,b,c');
commit;

• 查看是否使用Cluster Index，語句如下。

  explain select * from tmp where a > 1;

  

• 查看是否使用Bitmap Index，語句如下。

  explain select * from tmp where c = 1;

  

• 查看是否使用Segment Key，語句如下。

  explain select * from tmp where b > 1;