华为云用户手册

优化说明 通常优化器总会选择最优的执行计划，但是众所周知代价估算，尤其是中间结果集的代价估算一般会有比较大的偏差，这种比较大的偏差就可能会导致agg的计算方式出现比较大的偏差，这时候就需要通过best_agg_plan进行agg计算模型的干预。 一般来说，当agg汇聚的收敛度很小时，即结果集的个数在agg之后并没有明显变少时（经验上以5倍为临界点），选择redistribute+hashagg执行方式，否则选择hashagg+redistribute+hashagg执行方式。

优化说明 此优化的核心就是消除子查询。分析业务场景发现a.ca_address_sk不为null，那么从SQL语义出发，可以等价改写SQL为： 12345 select count(*) from customer_address_001 a4, customer_address_001 awhere a4.ca_address_sk = a.ca_address_skgroup by a.ca_address_sk; 为了保证改写的等效性，在customer_address_001. ca_address_sk加了not null约束。

优化分析 上述两个特征表明了此SQL语句存在极为严重的计算倾斜。进一步向HashJoin算子的下层分析发现Seq Scan on s_riskrate_setting也存在极为严重的计算倾斜[38.885,2940.983]。根据Scan的含义推测此计划性能问题的根源在于表s_riskrate_setting数据的分布倾斜。实际分析之后确实发现表s_riskrate_setting存在严重的数据倾斜。整改之后性能从94s提升为50s。

现象描述 某局点测试过程中EXPLAIN ANALYZE后有如下情况： 从执行信息上比较明确的可以看出HashJoin是整个计划的性能瓶颈点，并且从HashJoin的执行时间信息[2657.406,93339.924](数值的具体含义请参见SQL执行计划详解)，上可以看出HashJoin在不同的DN上存在严重的计算偏斜。 同时在Memory Information(如下图)中可以看出各个节点的内存资源消耗也存在极为严重的偏斜。

优化分析 分析发现上述计划的性能瓶颈点为lfbank.f_ev_dp_kdpl_zhminx的scan。进一步分析该表的Scan条件如下： 尝试把lfbank.f_ev_dp_kdpl_zhminx表修改为列存表，然后在yezdminc列上建PCK（局部聚簇），并设置PARTIAL_CLUSTER_ROWS=100000000。执行计划优化为： 此方法实际是靠牺牲数据导入时的性能来提升业务查询性能。 此方法导致局部排序的元组数增加，需要增大psort_work_mem来提高排序效率。

现象描述 在GaussDB中行存表天然的使用行执行引擎，列存表天然的使用列执行引擎。如果一个SQL语句涉及的表既有行存表又有列存表，系统会自动选择行执行引擎。由于列执行引擎的性能(除indexscan相关的算子)比行执行引擎性能要好很多，因此一般建议使用列存表。特别是对一些中间结果集转储的表，一定要分析清楚，使用合适的表存储类型。 某局点测试过程遇到如下的执行计划，客户希望将性能提升至3s内返回结果。

现象描述 查询与销售部所有员工的信息： 1234567 SELECT staff_id,first_name,last_name,employment_id,state_name,city FROM staffs,sections,states,places WHERE sections.section_name='Sales' AND staffs.section_id = sections.section_id AND sections.place_id = places.place_id AND places.state_id = states.state_id ORDER BY staff_id;

优化分析 如果将a作为t1和t2的分布列： 12 CREATE TABLE t1 (a int, b int) DISTRIBUTE BY HASH (a);CREATE TABLE t2 (a int, b int) DISTRIBUTE BY HASH (a); 则执行计划将存在“Streaming”，导致DN之间存在较大通信数据量，如图1所示。 图1 选择合适的分布列案例（一） 如果将a作为t1的分布列，将b作为t2的分布列： 12 CREATE TABLE t1 (a int, b int) DISTRIBUTE BY HASH (a);CREATE TABLE t2 (a int, b int) DISTRIBUTE BY HASH (b); 则执行计划将不包含“Streaming”，减少DN之间存在的通信数据量，从而提升查询性能，如图2所示。 图2 选择合适的分布列案例（二）

检查隐式转换的性能问题 在某些场景下，数据类型的隐式转换可能会导致潜在的性能问题。请看如下的场景： SET enable_fast_query_shipping = off;CREATE TABLE t1(c1 VARCHAR, c2 VARCHAR);CREATE INDEX on t1(c1);EXPLAIN verbose SELECT * FROM t1 WHERE c1 = 10; 上述查询的执行计划如下： c1的数据类型是varchar，当查询的过滤条件为c1 = 10时，优化器默认将c1隐式转换为bigint类型，导致两个后果： 不能进行DN裁剪，计划下发到所有DN上执行。 计划中不能使用Index Scan方式扫描数据。 这会引起潜在的性能问题。 当知道了问题原因后，我们可以做针对性的SQL改写。对于上面的场景，只要将过滤条件中的常量显示转换为varchar类型，结果如下： EXPLAIN verbose SELECT * FROM t1 WHERE c1 = 10::varchar; 为了提前识别隐式类型转换可能带来的性能影响，我们提供了一个guc option：check_implicit_conversions。打开该参数后，对于查询中出现的隐式类型转换的索引列，在路径生成阶段进行检查，如果发现索引列没有生成候选的索引扫描路径，则会通过报错的形式提示给用户。举例如下： SET check_implicit_conversions = on;SELECT * FROM t1 WHERE c1 = 10;ERROR: There is no optional index path for index column: "t1"."c1".Please check for potential performance problem. 参数check_implicit_conversions只用于检查隐式类型转换引起的潜在性能问题，在正式生产环境中请关闭该参数（该参数默认关闭）。 在将check_implicit_conversions打开时，必须同时关闭enable_fast_query_shipping参数，否则由于后一个参数的作用，无法查看对隐式类型转换修复的结果。 一个表的候选路径可能包括seq scan和index scan等多个可能的数据扫描方式，最终执行计划使用的表扫描方式是由执行计划的代价来决定的，因此即使生成了索引扫描的候选路径，也可能生成的最终执行计划中使用其它扫描方式。 父主题： SQL调优指南

Plan Hint实际调优案例 本节以TPC-DS标准测试的Q24的部分语句为例，在1000X，24DN环境上，说明使用plan hint进行实际调优的过程。示例如下： 1 2 3 4 5 6 7 8 9101112131415161718192021222324252627282930313233343536 select avg(netpaid) from(select c_last_name,c_first_name,s_store_name,ca_state,s_state,i_color,i_current_price,i_manager_id,i_units,i_size,sum(ss_sales_price) netpaidfrom store_sales,store_returns,store,item,customer,customer_addresswhere ss_ticket_number = sr_ticket_numberand ss_item_sk = sr_item_skand ss_customer_sk = c_customer_skand ss_item_sk = i_item_skand ss_store_sk = s_store_skand c_birth_country = upper(ca_country)and s_zip = ca_zipand s_market_id=7group by c_last_name,c_first_name,s_store_name,ca_state,s_state,i_color,i_current_price,i_manager_id,i_units,i_size); 该语句的初始计划如下，运行时间110s： 该计划中，第10层算子使用broadcast性能较差，由于第11层算子估算行数为2140，比实际行数严重低估。错误行数估算主要来源于第13层算子的行数低估，根因是第13层hashjoin中，使用store_sales的(ss_ticket_number, ss_item_sk)列和store_returns的(sr_ticket_number, sr_item_sk)列进行关联，由于缺少多列相关性的估算导致行数严重低估。 2. 使用如下的rows hint进行调优后，计划如下，运行时间318s： 12 select avg(netpaid) from(select /*+rows(store_sales store_returns * 11270)*/ c_last_name ... 时间反而劣化了，原因是第8层hashjoin过慢引起第9层redistribute时间过慢导致，其中第9层redistribute并没有数据倾斜，hashjoin慢的原因是由于第18层redistribute后数据倾斜导致。 3. 经过实际数据查证，customer_address的两个join列的不同值数目较少，使用其进行join容易出现数据倾斜，故把customer_address放到最后进行join。使用如下的hint进行调优后，计划如下，运行时间116s： 1234 select avg(netpaid) from(select /*+rows(store_sales store_returns *11270)leading((store_sales store_returns store item customer) customer_address)*/c_last_name ... 发现时间基本花在了第6层redistribute算子上，需要进一步优化。 4. 由于最后一层redistribute包含倾斜，所以时间较长。为了避免倾斜，需要将item表放在最后join，由于item表的join并不能使行数减少。修改hint如下并执行，计划如下，运行时间120s： 1234 select avg(netpaid) from(select /*+rows(store_sales store_returns *11270)leading((customer_address (store_sales store_returns store customer) item))c_last_name ... 该计划中的redistribute问题并没有解决，因为第22层item表做了broadcast，导致与customer_address表join后的倾斜并没有被消除掉。 5. 增加如下禁止item表做broadcast的hint，使与customer_address join的表做redistribute（也可以进行join表redistribute的hint），计划如下，运行时间105s： 12345 select avg(netpaid) from(select /*+rows(store_sales store_returns *11270)leading((customer_address (store_sales store_returns store customer) item))no broadcast(item)*/c_last_name ... 6. 发现最后一层使用单层Agg，但行数缩减较多。使用相同的hint，同时结合参数best_agg_plan=3进行双层Agg调优，最终计划如下图所示，运行时间94s，完成调优。 如果有统计信息变更引起的查询劣化，可以考虑用plan hint来调整到之前的查询计划。这里以TPCH-Q17为例，在收集default_statistics_target设置为–2的统计信息之后，计划相比于默认统计信息发生劣化。 1. 默认统计信息（default_statistics_target设置为100）的计划如下： 2. 统计信息变更（default_statistics_target设置为–2）的计划如下： 3. 经过对比，劣化的原因主要为lineitem和part表join时stream类型由BroadCast变更为Redistribute导致。可以对语句进行stream方式的hint来调整到之前的计划，例如： 父主题： 使用Plan Hint进行调优

示例 强制使用Custom Plan 1234 set enable_fast_query_shipping = off;create table t (a int, b int, c int);prepare p as select /*+ use_cplan */ * from t where a = $1;explain execute p(1); 计划如下。可以看到过滤条件为入参的实际值，即此计划为Custom Plan。 强制使用Generic Plan 123 deallocate p;prepare p as select /*+ use_gplan */ * from t where a = $1;explain execute p(1); 计划如下。可以看到过滤条件为待填充的入参，即此计划为Generic Plan。

Hint的错误、冲突及告警 Plan Hint的结果会体现在计划的变化上，可以通过explain来查看变化。 Hint中的错误不会影响语句的执行，只是不能生效，该错误会根据语句类型以不同方式提示用户。对于explain语句，hint的错误会以warning形式显示在界面上，对于非explain语句，会以debug1级别日志显示在日志中，关键字为PLANHINT。 hint的错误分为以下类型： 语法错误 语法规则树归约失败，会报错，指出出错的位置。 例如：hint关键字错误，leading hint或join hint指定2个表以下，其它hint未指定表等。一旦发现语法错误，则立即终止hint的解析，所以此时只有错误前面的解析完的hint有效。 例如： 1 leading((t1 t2)) nestloop(t1) rows(t1 t2 #10) nestloop(t1)存在语法错误，则终止解析，可用hint只有之前解析的leading((t1 t2))。 语义错误 表不存在，存在多个，或在leading或join中出现多次，均会报语义错误。 scanhint中的index不存在，会报语义错误。 另外，如果子查询提升后，同一层出现多个名称相同的表，且其中某个表需要被hint，hint会存在歧义，无法使用，需要为相同表增加别名规避。 hint重复或冲突 如果存在hint重复或冲突，只有第一个hint生效，其它hint均会失效，会给出提示。 hint重复是指，hint的方法及表名均相同。例如：nestloop(t1 t2) nestloop(t1 t2)。 hint冲突是指，table list一样的hint，存在不一样的hint，hint的冲突仅对于每一类hint方法检测冲突。 例如：nestloop (t1 t2) hashjoin (t1 t2)，则后面与前面冲突，此时hashjoin的hint失效。注意：nestloop(t1 t2)和no mergejoin(t1 t2)不冲突。 leading hint中的多个表会进行拆解。例如：leading ((t1 t2 t3))会拆解成：leading((t1 t2)) leading(((t1 t2) t3))，此时如果存在leading((t2 t1))，则两者冲突，后面的会被丢弃。（例外：指定内外表的hint若与不指定内外表的hint重复，则始终丢弃不指定内外表的hint。） 子链接提升后hint失效 子链接提升后的hint失效，会给出提示。通常出现在子链接中存在多个表连接的场景。提升后，子链接中的多个表不再作为一个整体出现在join中。 列类型不支持重分布 对于skew hint来说，目的是为了进行重分布时的调优，所以当hint列的类型不支持重分布时，hint将无效。 hint未被使用 非等值join使用hashjoin hint或mergejoin hint 不包含索引的表使用indexscan hint或indexonlyscan hint 通常只有在索引列上使用过滤条件才会生成相应的索引路径，全表扫描将不会使用索引，因此使用indexscan hint或indexonlyscan hint将不会使用 indexonlyscan只有输出列仅包含索引列才会使用，否则指定时hint不会被使用 多个表存在等值连接时，仅尝试有等值连接条件的表的连接，此时没有关联条件的表之间的路径将不会生成，所以指定相应的leading，join，rows hint将不使用，例如：t1 t2 t3表join，t1和t2, t2和t3有等值连接条件，则t1和t3不会优先连接，leading(t1 t3)不会被使用。 生成stream计划时，如果表的分布列与join列相同，则不会生成redistribute的计划；如果不同，且另一表分布列与join列相同，只能生成redistribute的计划，不会生成broadcast的计划，指定相应的hint则不会被使用。 如果子链接未被提升，则blockname hint不会被使用。 对于skew hint，hint未被使用可能由于： 计划中不需要进行重分布。 hint指定的列为包含分布键。 hint指定倾斜信息有误或不完整，如对于join优化未指定值。 倾斜优化的GUC参数处于关闭状态。 父主题： 使用Plan Hint进行调优

参数说明 param：表示参数名。 value：表示参数的取值。 目前支持使用Hint设置生效的参数有： 布尔类： enable_bitmapscan, enable_hashagg, enable_hashjoin, enable_indexscan, enable_indexonlyscan, enable_material, enable_mergejoin, enable_nestloop, enable_index_nestloop, enable_seqscan, enable_sort, enable_tidscan, enable_stream_operator, enable_stream_recursive, enable_broadcast, enable_fast_query_shipping, enable_trigger_shipping, enable_remotejoin, enable_remotegroup, enable_remotelimit, enable_remotesort 整形类： best_agg_plan, query_dop 浮点类： cost_weight_index, default_limit_rows, seq_page_cost, random_page_cost, cpu_tuple_cost, cpu_index_tuple_cost, cpu_operator_cost, effective_cache_size 枚举类： try_vector_engine_strategy 字符串类： node_name 通过设置node_name可以指定当前的sql下发到node_name对应的dn上去执行。 示例： select /*+ set(node_name datanode1) */ from table_name; 其中，datanode1是从 pgxc_node 系统表里查询出来的数据节点的名称（不用加引号），table_name 是表名。该查询表示直接去datanode1上执行查询。 node_name只支持在select语句里设置，如果在其他语句里设置将会不生效。 node_name只支持设置data node名字，不支持设置coodninator名字。 node_name不支持通过SET语句进行修改，只能用在plan hint里。 node_name不支持通过gs_guc进行修改。 node_name仅支持简单查询语句，不支持带union，union all, 子查询，多表关联等复杂查询语句。 支持普通用户执行。 不支持与行级访问控制同时使用，同时使用会报错。 设置不在白名单中的参数，参数取值不合法，或hint语法错误时，不会影响查询执行的正确性。使用explain(verbose on)执行可以看到hint解析错误的报错提示。 GUC参数的hint只在最外层查询生效，子查询内的GUC参数hint不生效。 视图定义内的GUC参数hint不生效。 CREATE TABLE ... AS ... 查询最外层的GUC参数hint可以生效。

建议 推荐使用两个表*的hint。对于两个表的采用*操作符的hint，只要两个表出现在join的两端，都会触发hint。例如：设置hint为rows(t1 t2 * 3)，对于(t1 t3 t4)和(t2 t5 t6)join时，由于t1和t2出现在join的两端，所以其join的结果集也会应用该hint规则乘以3。 rows hint支持在单表、多表、function table及subquery scan table的结果集上指定hint。

参数说明 src, src1, src2表示predpush下推candidates一侧表集合。 dest表示predpush下推所指定的dest表也就是目标表。 predpush如果没有逗号表示所有表都是candidates表, 如果有逗号就说明同时指定了candidates表和dest表。 使用predpush hint将过滤表达式尽可能移至靠近数据源的位置以达到查询优化的目的。 使用predpush hint需要确保rewrite_rule GUC参数包含PREDPUSH|REDPUSHFORCE|PREDPUSHNORMAL选项。 subquery_block也可以是视图/物化视图。

存储层数据倾斜 GaussDB数据库中，数据分布存储在各个DN上，通过分布式执行提高查询的效率。但是，如果数据分布存在倾斜，则会导致分布式执行某些DN成为瓶颈，影响查询性能。这种情况通常是由于分布列选择不合理，可以通过调整分布列的方式解决。 例如下例： 1 2 3 4 5 6 7 8 91011121314151617181920 openGauss=# explain performance select count(*) from inventory;5 --CStore Scan on lmz.inventory dn_6001_6002 (actual time=0.444..83.127 rows=42000000 loops=1) dn_6003_6004 (actual time=0.512..63.554 rows=27000000 loops=1) dn_6005_6006 (actual time=0.722..99.033 rows=45000000 loops=1) dn_6007_6008 (actual time=0.529..100.379 rows=51000000 loops=1) dn_6009_6010 (actual time=0.382..71.341 rows=36000000 loops=1) dn_6011_6012 (actual time=0.547..100.274 rows=51000000 loops=1) dn_6013_6014 (actual time=0.596..118.289 rows=60000000 loops=1) dn_6015_6016 (actual time=1.057..132.346 rows=63000000 loops=1) dn_6017_6018 (actual time=0.940..110.310 rows=54000000 loops=1) dn_6019_6020 (actual time=0.231..41.198 rows=21000000 loops=1) dn_6021_6022 (actual time=0.927..114.538 rows=54000000 loops=1) dn_6023_6024 (actual time=0.637..118.385 rows=60000000 loops=1) dn_6025_6026 (actual time=0.288..32.240 rows=15000000 loops=1) dn_6027_6028 (actual time=0.566..118.096 rows=60000000 loops=1) dn_6029_6030 (actual time=0.423..82.913 rows=42000000 loops=1) dn_6031_6032 (actual time=0.395..78.103 rows=39000000 loops=1) dn_6033_6034 (actual time=0.376..51.052 rows=24000000 loops=1) dn_6035_6036 (actual time=0.569..79.463 rows=39000000 loops=1) 在performance信息中，可以看到inventory表各DN的scan行数，发现各DN的行数差距较大，最大的为63000000，最小的只有15000000，差了4倍。这个差距对于数据扫描的性能影响还可以接受，但如果上层有join算子，则影响较大。 通常，数据表在各DN上是hash分布的，因此分布列的选择很重要。通过table_skewness()来查看上述inventory表在各DN的数据分布倾斜，查询结果如下： 1 2 3 4 5 6 7 8 910111213141516171819202122 openGauss=# select table_skewness('inventory'); table_skewness ------------------------------------------ ("dn_6015_6016 ",63000000,8.046%) ("dn_6013_6014 ",60000000,7.663%) ("dn_6023_6024 ",60000000,7.663%) ("dn_6027_6028 ",60000000,7.663%) ("dn_6017_6018 ",54000000,6.897%) ("dn_6021_6022 ",54000000,6.897%) ("dn_6007_6008 ",51000000,6.513%) ("dn_6011_6012 ",51000000,6.513%) ("dn_6005_6006 ",45000000,5.747%) ("dn_6001_6002 ",42000000,5.364%) ("dn_6029_6030 ",42000000,5.364%) ("dn_6031_6032 ",39000000,4.981%) ("dn_6035_6036 ",39000000,4.981%) ("dn_6009_6010 ",36000000,4.598%) ("dn_6003_6004 ",27000000,3.448%) ("dn_6033_6034 ",24000000,3.065%) ("dn_6019_6020 ",21000000,2.682%) ("dn_6025_6026 ",15000000,1.916%)(18 rows) 通过查询建表定义，可以发现，目前该表是以inv_date_sk作为分布列的，导致存在倾斜。通过查看各列的数据分布情况，改为inv_item_sk作为分布列，则倾斜情况分布如下： 1 2 3 4 5 6 7 8 910111213141516171819202122 openGauss=# select table_skewness('inventory'); table_skewness ------------------------------------------ ("dn_6001_6002 ",43934200,5.611%) ("dn_6007_6008 ",43829420,5.598%) ("dn_6003_6004 ",43781960,5.592%) ("dn_6031_6032 ",43773880,5.591%) ("dn_6033_6034 ",43763280,5.589%) ("dn_6011_6012 ",43683600,5.579%) ("dn_6013_6014 ",43551660,5.562%) ("dn_6027_6028 ",43546340,5.561%) ("dn_6009_6010 ",43508700,5.557%) ("dn_6023_6024 ",43484540,5.554%) ("dn_6019_6020 ",43466800,5.551%) ("dn_6021_6022 ",43458500,5.550%) ("dn_6017_6018 ",43448040,5.549%) ("dn_6015_6016 ",43247700,5.523%) ("dn_6005_6006 ",43200240,5.517%) ("dn_6029_6030 ",43181360,5.515%) ("dn_6025_6026 ",43179700,5.515%) ("dn_6035_6036 ",42960080,5.487%)(18 rows) 数据分布倾斜的问题得到解决。 除了table_skewness()视图外，当前版本还提供了table_distribution函数和PGXC_GET_TABLE_SKEWNESS视图，可以更加高效的查询各表的数据倾斜情况。

统计信息调优介绍 GaussDB是基于代价估算生成的最优执行计划。优化器需要根据analyze收集的统计信息进行行数估算和代价估算，因此统计信息对优化器行数估算和代价估算起着至关重要的作用。通过analyze收集全局统计信息，主要包括：pg_class表中的relpages和reltuples；pg_statistic表中的stadistinct、stanullfrac、stanumbersN、stavaluesN、histogram_bounds等。

更多优化示例 示例1：修改基表为replicate表，并且在过滤列上创建索引。 123 create table master_table (a int);create table sub_table(a int, b int);select a from master_table group by a having a in (select a from sub_table); 上述事例中存在一个相关性子查询，为了提升查询的性能，可以将sub_table修改为一个relication表，并且在字段a上创建一个index。

算子级调优介绍 一个查询语句要经过多个算子步骤才会输出最终的结果。由于各别算子耗时过长导致整体查询性能下降的情况比较常见。这些算子是整个查询的瓶颈算子。通用的优化手段是EXPLAIN ANALYZE/PERFORMANCE命令查看执行过程的瓶颈算子，然后进行针对性优化。 如下面的执行过程信息中，Hashagg算子的执行时间占总时间的：(51016-13535)/ 56476 ≈66%，此处Hashagg算子就是这个查询的瓶颈算子，在进行性能优化时应当优先考虑此算子的优化。

语句下推介绍 目前，GaussDB优化器在分布式框架下制定语句的执行策略时，有三种执行计划方式：生成下推语句计划、生成分布式执行计划、生成发送语句的分布式执行计划。 下推语句计划：指直接将查询语句从CN发送到DN进行执行，然后将执行结果返回给CN。 分布式执行计划：指CN对查询语句进行编译和优化，生成计划树，再将计划树发送给DN进行执行，并在执行完毕后返回结果到CN。 发送语句的分布式执行计划：上述两种方式都不可行时，将可下推的查询部分组成查询语句（多为基表扫描语句）下推到DN进行执行，获取中间结果到CN，然后在CN执行剩下的部分。 在第3种策略中，要将大量中间结果从DN发送到CN，并且要在CN运行不能下推的部分语句，会导致CN成为性能瓶颈（带宽、存储、计算等）。在进行性能调优的时候，应尽量避免只能选择第3种策略的查询语句。 执行语句不能下推是因为语句中含有不支持下推的函数或者不支持下推的语法。一般都可以通过等价改写规避执行计划不能下推的问题。

不支持下推的函数 首先介绍函数的易变性。在GaussDB中共分三种形态： IMMUTABLE 表示该函数在给出同样的参数值时总是返回同样的结果。 STABLE 表示该函数不能修改数据库，对相同参数值，在同一次表扫描里，该函数的返回值不变，但是返回值可能在不同SQL语句之间变化。 VOLATILE 表示该函数值可以在一次表扫描内改变，因此不会做任何优化。 函数易变性可以查询pg_proc的provolatile字段获得，i代表IMMUTABLE，s代表STABLE，v代表VOLATILE。另外，在pg_proc中的proshippable字段，取值范围为t/f/NULL，这个字段与provolatile字段一起用于描述函数是否下推。 如果函数的provolatile属性为i，则无论proshippable的值是否为t，则函数始终可以下推。 如果函数的provolatile属性为s或v，则仅当proshippable的值为t时，函数可以下推。 random，exec_hadoop_sql，exec_on_extension如果出现CTE中，也不下推。因为这种场景下下推可能出现结果错误。 对于用户自定义函数，可以在创建函数的时候指定provolatile和proshippable属性的值，详细请参考CREATE FUNCTION。 对于函数不能下推的场景： 如果是系统函数，建议根据业务等价替换这个函数。 如果是自定义函数，建议分析客户业务场景，看函数的provolatile和proshippable属性定义是否正确。

执行信息 在SQL调优过程中经常需要执行EXPLAIN ANALYZE或EXPLAIN PERFORMANCE查看SQL语句实际执行信息，通过对比实际执行与优化器的估算之间的差别来为优化提供依据。EXPLAIN PERFORMANCE相对于EXPLAIN ANALYZE增加了每个DN上的执行信息。 以如下SQL语句为例： select count(1) from tb1; 执行EXPLAIN PERFORMANCE输出为： 图中显示执行信息分为以下7个部分 以表格的形式将计划显示出来，包含有11个字段，分别是：id、operation、A-time、A-rows、E-rows、E-distinct、Peak Memory、E-memory、A-width、E-width和E-costs。其中计划类字段（id、operation以及E开头字段）的含义与执行EXPLAIN时的含义一致，详见执行计划小节中的说明。A-time、A-rows、E-distinct、Peak Memory、A-width的含义说明如下： A-time：当前算子执行完成时间，一般DN上执行的算子的A-time是由[]括起来的两个值，分别表示此算子在所有DN上完成的最短时间和最长时间。 A-rows：表示当前算子的实际输出元组数。 E-distinct：表示hashjoin算子的distinct估计值。 Peak Memory：此算子在每个DN上执行时使用的内存峰值。 A-width：表示当前算子每行元组的实际宽度，仅对于重内存使用算子会显示，包括：(Vec)HashJoin、(Vec)HashAgg、(Vec) HashSetOp、(Vec)Sort、(Vec)Materialize算子等，其中(Vec)HashJoin计算的宽度是其右子树算子的宽度，会显示在其右子树上。 Predicate Information (identified by plan id)： 这一部分主要显示的是静态信息，即在整个计划执行过程中不会变的信息，主要是一些join条件和一些filter信息。 Memory Information (identified by plan id)： 这一部分显示的是整个计划中会将内存的使用情况打印出来的算子的内存使用信息，主要是Hash、Sort算子，包括算子峰值内存（peak memory），控制内存（control memory），估算内存使用（operator memory），执行时实际宽度（width），内存使用自动扩展次数（auto spread num），是否提前下盘（early spilled），以及下盘信息，包括重复下盘次数（spill Time(s)），内外表下盘分区数（inner/outer partition spill num），下盘文件数（temp file num），下盘数据量及最小和最大分区的下盘数据量（written disk IO [min, max] ）。 Targetlist Information (identified by plan id) 这一部分显示的是每一个算子输出的目标列。 DataNode Information (identified by plan id)： 这一部分会将各个算子的执行时间、CPU、buffer的使用情况全部打印出来。 User Define Profiling 这一部分显示的是CN和DN、DN和DN建连的时间，以及存储层的一些执行信息。 ====== Query Summary =====： 这一部分主要打印总的执行时间和网络流量，包括了各个DN上初始化和结束阶段的最大最小执行时间、CN上的初始化、执行、结束阶段的时间，以及当前语句执行时系统可用内存、语句估算内存等信息。 A-rows和E-rows的差异体现了优化器估算和实际执行的偏差度。一般来说，他们偏差越大，我们越可以认为优化器生成的计划的越不可信，人工干预调优的必要性越大。 A-time中的两个值偏差越大，表明此算子的计算偏斜(在不同DN上执行时间差异)越大，人工干预调优的必要性越大。 Max Query Peak Memory经常用来估算SQL语句耗费内存，也被用来作为SQL语句调优时运行态内存参数设置的重要依据。一般会以EXPLAIN ANALYZE或EXPLAIN PERFORMANCE的输出作为进一步调优的输入。

执行计划 以如下SQL语句为例： 12345 select cjxh, count(1) from dwcjkgroup by cjxh; 执行EXPLAIN的输出为： 执行计划字段解读（横向）： id：执行算子节点编号。 operation：具体的执行节点算子名称。 Vector前缀的算子是指向量化执行引擎算子，一般出现含有列存表的Query中。 Streaming是一个特殊的算子，它实现了分布式架构的核心数据shuffle功能，Streaming共有三种形态，分别对应了分布式结构下不同的数据shuffle功能： Streaming (type: GATHER)：作用是coordinator从DN收集数据。 Streaming(type: REDISTRIBUTE)：作用是DN根据选定的列把数据重分布到所有的DN。 Streaming(type: BROADCAST)：作用是把当前DN的数据广播给其他所有的DN E-rows：每个算子估算的输出行数。 E-memory：DN上每个算子估算的内存使用量，只有DN上执行的算子会显示。某些场景会在估算的内存使用量后使用括号显示该算子在内存资源充足下可以自动扩展的内存上限。 E-width：每个算子输出元组的估算宽度。 E-costs：每个算子估算的执行代价。 E-costs是优化器根据成本参数定义的单位来衡量的，习惯上以磁盘页面抓取为1个单位， 其它开销参数将参照它来设置。 每个节点的开销（E-costs值）包括它的所有子节点的开销。 开销只反映了优化器关心的东西，并没有把结果行传递给客户端的时间考虑进去。虽然这个时间可能在实际的总时间里占据相当重要的分量，但是被优化器忽略了，因为它无法通过修改规划来改变。 执行计划层级解读（纵向）： 第一层：CStore Scan on dwcjk 表扫描算子，用CStore Scan的方式扫描表dwcjk。这一层的作用是把表dwcjk的数据从buffer或者磁盘上读上来输送给上层节点参与计算。 第二层：Vector Hash Aggregate 聚合算子，作用是把下层计算输送上来的算子做聚合操作(group by)。 第三层：Vector Streaming (type: GATHER) Shuffle算子，此处GATHER类型的Shuffle算子作用是把数据从DN汇聚到CN。 第四层：Row Adapter 存储格式转化算子，主要作用是把内存中列式格式数据转为行式数据，以便客户端展示。 需要注意的是最顶层算子为Data Node Scan时，需要设置enable_fast_query_shipping为off才能看到具体的执行计划，如下面这个计划： 123456 openGauss=# explain select cjxh, count(1) from dwcjk group by cjxh; QUERY PLAN -------------------------------------------------- Data Node Scan (cost=0.00..0.00 rows=0 width=0) Node/s: All datanodes(2 rows) 设置enable_fast_query_shipping参数之后，执行计划显示如下： 执行计划中的关键字说明： 表访问方式 Seq Scan 全表顺序扫描。 Index Scan 优化器决定使用两步的规划：最底层的规划节点访问一个索引，找出匹配索引条件的行的位置，然后上层规划节点真实地从表中抓取出那些行。独立地抓取数据行比顺序地读取它们的开销高很多，但是因为并非所有表的页面都被访问了，这么做实际上仍然比一次顺序扫描开销要少。使用两层规划的原因是，上层规划节点在读取索引标识出来的行位置之前，会先将它们按照物理位置排序，这样可以最小化独立抓取的开销。 如果在WHERE里面使用的好几个字段上都有索引，那么优化器可能会使用索引的AND或OR的组合。但是这么做要求访问两个索引，因此与只使用一个索引，而把另外一个条件只当作过滤器相比，这个方法未必是更优。 索引扫描可以分为以下几类，他们之间的差异在于索引的排序机制。 Bitmap Index Scan 使用位图索引抓取数据页。 Index Scan using index_name 使用简单索引搜索，该方式表的数据行是以索引顺序抓取的，这样就令读取它们的开销更大，但是这里的行少得可怜，因此对行位置的额外排序并不值得。最常见的就是看到这种规划类型只抓取一行，以及那些要求ORDER BY条件匹配索引顺序的查询。因为那时候没有多余的排序步骤是必要的以满足ORDER BY。 表连接方式 Nested Loop 嵌套循环，适用于被连接的数据子集较小的查询。在嵌套循环中，外表驱动内表，外表返回的每一行都要在内表中检索找到它匹配的行，因此整个查询返回的结果集不能太大（不能大于10000），要把返回子集较小的表作为外表，而且在内表的连接字段上建议要有索引。 (Sonic) Hash Join 哈希连接，适用于数据量大的表的连接方式。优化器使用两个表中较小的表，利用连接键在内存中建立hash表，然后扫描较大的表并探测散列，找到与散列匹配的行。Sonic和非Sonic的Hash Join的区别在于所使用hash表结构不同，不影响执行的结果集。 Merge Join 归并连接，通常情况下执行性能差于哈希连接。如果源数据已经被排序过，在执行融合连接时，并不需要再排序，此时融合连接的性能优于哈希连接。 运算符 sort 对结果集进行排序。 filter EXPLAIN输出显示WHERE子句当作一个"filter"条件附属于顺序扫描计划节点。这意味着规划节点为它扫描的每一行检查该条件，并且只输出符合条件的行。预计的输出行数降低了，因为有WHERE子句。不过，扫描仍将必须访问所有 10000 行，因此开销没有降低；实际上它还增加了一些（确切的说，通过10000 * cpu_operator_cost）以反映检查WHERE条件的额外CPU时间。 LIMIT LIMIT限定了执行结果的输出记录数。如果增加了LIMIT，那么不是所有的行都会被检索到。

规格约束 告警字符串长度上限为2048。如果告警信息超过这个长度（例如存在大量未收集统计信息的超长表名，列名等信息）则不告警，只上报warning： WARNING, "Planner issue report is truncated, the rest of planner issues will be skipped" 如果query存在limit节点（即查询语句中包含limit），则不会上报limit节点以下的Operator级别的告警。 对于“数据倾斜”和“估算不准”两种类型告警，在某一个plan树结构下，只上报下层节点的告警，上层节点不再重复告警。这主要是因为这两种类型的告警可能是因为底层触发上层的。例如，如果在scan节点已经存在数据倾斜，那么在上层的hashagg等其他算子很可能也出现数据倾斜。

告警场景 目前支持对以下7种导致性能问题的场景上报告警。 多列/单列统计信息未收集 如果存在单列或者多列统计信息（当前特性是实验室特性，使用时请联系华为工程师提供技术支持）未收集，则上报相关告警。调优方法可以参考更新统计信息和统计信息调优。 需要特别注意的是，对于基于OBS外表（当前特性是实验室特性，使用时请联系华为工程师提供技术支持）的查询，如果未收集统计信息也会上报统计信息未收集的告警，但是由于OBS外表（当前特性是实验室特性，使用时请联系华为工程师提供技术支持）的analyze的性能比较差，因此，需要用户对这种场景下告警是否通过analyze收集统计信息，以获取更优的性能，和查询本身的复杂度做权衡。 告警信息示例： 整表的统计信息未收集： Statistic Not Collect: schema_test.t1 单列统计信息未收集： Statistic Not Collect: schema_test.t2(c1,c2) 多列统计信息未收集: Statistic Not Collect: schema_test.t3((c1,c2)) 单列和多列统计信息未收集： Statistic Not Collect: schema_test.t4(c1,c2) schema_test.t4((c1,c2)) SQL不下推 对于不下推的SQL，尽可能详细上报导致不下推的原因。调优方法可以参考案例语句下推调优。 对于函数导致的不下推，告警导致不下推的函数名信息； 对于不支持下推的语法，会告警对应语法不支持下推，例如：含有With Recursive，Distinct On，row表达式，返回值为record类型的，会告警相应语法不支持下推等等。 告警信息示例： SQL is not plan-shipping, reason : "With Recursive" can not be shipped"SQL is not plan-shipping, reason : "Function now() can not be shipped"SQL is not plan-shipping, reason : "Function string_agg() can not be shipped" HashJoin中大表做内表 如果在表连接过程中使用了Hashjoin(可以在GS_WLM_SESSION_HISTORY的query_plan字段中查看到)，且连接的内表行数是外表行数的10倍或以上；同时内表在每个DN上的平均行数大于10万行，且发生了下盘，则上报相关告警。调优方法可以参考使用plan hint调优执行计划。 告警信息示例： PlanNode[7] Large Table is INNER in HashJoin “Vector Hash Aggregate” 大表等值连接使用Nestloop 如果在表连接过程中使用了nestloop(可以在使用plan hint调优执行计划的query_plan字段中查看到)，并且两个表中较大表的行数平均每个DN上的行数大于10万行、表的连接中存在等值连接，则上报相关告警。调优方法可以参考使用plan hint调优执行计划。 告警信息示例： PlanNode[5] Large Table with Equal-Condition use Nestloop"Nested Loop" 大表Broadcast 如果在Broadcast算子中，平均每DN的行数大于10万行，则告警大表broadcast。调优方法可以参考使用plan hint调优执行计划。 告警信息示例： PlanNode[5] Large Table in Broadcast "Streaming(type: BROADCAST dop: 1/2)" 数据倾斜 某表在各DN上的分布，存在某DN上的行数是另一DN上行数的10倍或以上，且有DN中的行数大于10万行，则上报相关告警。调优方法可以参考案例选择合适的分布列和数据倾斜调优。 告警信息示例： PlanNode[6] DataSkew:"Seq Scan", min_dn_tuples:0, max_dn_tuples:524288 估算不准 如果优化器的估算行数和实际行数中的较大值平均每DN行数大于10万行，并且估算行数和实际行数中较大值是较小值的10倍或以上，则上报相关告警。调优方法可以参考使用plan hint调优执行计划。 告警信息示例： PlanNode[5] Inaccurate Estimation-Rows: "Hash Join" A-Rows:0, E-Rows:52488

示例：Remote模式导出 规划数据服务器与集群处于同一内网，数据服务器IP为192.168.0.90，导出数据文件格式为CSV，所以规划的并行导出模式为Remote模式。 Remote模式并行导出数据操作示例如下所示： （可选）创建用户及其所属的用户组。此用户用于启动GDS。若该类用户及所属用户组已存在，可跳过此步骤。 groupadd gdsgrpuseradd -g gdsgrp gds_user 切换用户gds_user，创建数据文件存放目录“/output_data”，启动gds_user用户及所属的用户组。 su - gds_usermkdir -p /output_data 修改数据服务器上数据文件目录“/output_data”的属主为gds_user。 chown -R gds_user:gdsgrp /output_data 以gds_user用户登录数据服务器上分别启动GDS。 其中GDS安装路径为“/opt/bin/gds”，导出数据文件存放在“/output_data/”目录下，数据服务器所在IP为192.168.0.90，GDS侦听端口为5000，以后台方式运行。 /opt/bin/gds/gds -d /output_data -p 192.168.0.90:5000 -H 10.10.0.1/24 -D 在数据库中创建外表foreign_tpcds_reasons用于接收数据服务器上的数据。 其中设置的导出模式信息如下所示： 由于启动GDS时，设置的导出数据文件存放目录为“/output_data/”，GDS侦听端口为5000。创建的导出数据文件存放目录为“/output_data/”。所以设置参数“location”为“gsfs://192.168.0.90:5000/”。 设置导出的数据文件格式信息如下所示： 数据文件格式（format）为CSV。 编码格式（encoding）为UTF-8。 字段分隔符（delimiter）为E'\x20'。 引号字符（quote）为0x1b。 数据文件中空值（null）为没有引号的空字符串。 逃逸字符（escape）为默认值双引号。 数据文件是否包含标题行（header）为默认值false，即导出时数据文件第一行被识别为数据。 根据以上信息，创建的外表如下所示： 123456 openGauss=# CREATE FOREIGN TABLE foreign_tpcds_reasons( r_reason_sk integer not null, r_reason_id char(16) not null, r_reason_desc char(100)) SERVER gsmpp_server OPTIONS (LOCATION 'gsfs://192.168.0.90:5000/', FORMAT 'CSV',ENCODING 'utf8',DELIMITER E'\x20', QUOTE E'\x1b', NULL '') WRITE ONLY; 在数据库上，通过外表foreign_tpcds_reasons，将数据导出到数据文件中。 1 openGauss=# INSERT INTO foreign_tpcds_reasons SELECT * FROM reasons; 待数据导出完成后，以gds_user用户登录数据服务器，停止GDS。 其中GDS进程号为128954。 ps -ef|grep gdsgds_user 128954 1 0 15:03 ? 00:00:00 gds -d /output_data -p 192.168.0.90:5000 -Dgds_user 129003 118723 0 15:04 pts/0 00:00:00 grep gdskill -9 128954

示例：多线程导出 规划数据服务器与集群处于同一内网，数据服务器IP为192.168.0.90，导出的数据文件格式为CSV，同时导出2个目标表，所以规划使用Remote模式进行多线程导处。 Remote模式多线程导出数据操作示例如下所示： 登录GDS数据服务器，创建数据库用户及所属的用户组。 groupadd gdsgrpuseradd -g gdsgrp gds_user 切换用户gds_user，创建导出文件存放目录“/output_data”。 su - gds_usermkdir -p /output_data 修改数据服务器上数据文件目录“/output_data”的属主为gds_user。 chown -R gds_user:gdsgrp /output_data 以gds_user用户登录数据服务器上启动GDS。 其中GDS安装路径为“/opt/bin/gds”，导出数据文件存放在“/output_data/”目录下，数据服务器所在IP为192.168.0.90，GDS侦听端口为5000，以后台方式运行，设定并发度为2。 /opt/bin/gds/gds -d /output_data -p 192.168.0.90:5000 -H 10.10.0.1/24 -D -t 2 在GaussDB上，创建外表foreign_tpcds_reasons1和foreign_tpcds_reasons2用于接收数据服务器上的数据。 其中设置的导出模式信息如下所示： 由于启动GDS时，设置的导出数据文件存放目录为“/output_data/”，GDS侦听端口为5000。创建的导出数据文件存放目录为“/output_data/”。所以设置参数“location”为“gsfs://192.168.0.90:5000/”。 设置导出的数据文件格式信息如下所示： 数据文件格式（format）为CSV。 编码格式（encoding）为UTF-8。 字段分隔符（delimiter）为E'\x20'。 引号字符（quote）为0x1b。 数据文件中空值（null）为没有引号的空字符串。 逃逸字符（escape）为默认值双引号。 数据文件是否包含标题行（header）为默认值false，即导出时数据文件第一行被识别为数据。 根据以上信息，创建的外表foreign_tpcds_reasons1如下所示： 123456 openGauss=# CREATE FOREIGN TABLE foreign_tpcds_reasons1( r_reason_sk integer not null, r_reason_id char(16) not null, r_reason_desc char(100)) SERVER gsmpp_server OPTIONS (LOCATION 'gsfs://192.168.0.90:5000/', FORMAT 'CSV',ENCODING 'utf8', DELIMITER E'\x20', QUOTE E'\x1b', NULL '') WRITE ONLY; 参考以上设置，创建的外表foreign_tpcds_reasons2如下所示： 123456 openGauss=# CREATE FOREIGN TABLE foreign_tpcds_reasons2( r_reason_sk integer not null, r_reason_id char(16) not null, r_reason_desc char(100)) SERVER gsmpp_server OPTIONS (LOCATION 'gsfs://192.168.0.90:5000/', FORMAT 'CSV', DELIMITER E'\x20', QUOTE E'\x1b', NULL '') WRITE ONLY; 在数据库中通过外表foreign_tpcds_reasons1和foreign_tpcds_reasons2，将表reasons1和reasons2中的数据导出到目录“/output_data”中。 1 openGauss=# INSERT INTO foreign_tpcds_reasons1 SELECT * FROM reasons1; 1 openGauss=# INSERT INTO foreign_tpcds_reasons2 SELECT * FROM reasons2; 待数据导出完成后，以gds_user用户登录数据服务器，停止GDS。 其中GDS进程号为128954。 ps -ef|grep gdsgds_user 128954 1 0 15:03 ? 00:00:00 gds -d /output_data -p 192.168.0.90:5000 -D -t 2 gds_user 129003 118723 0 15:04 pts/0 00:00:00 grep gdskill -9 128954

示例：Local模式导出 集群总共有8个DN，其中每2个DN位于同一个物理节点上，共有4个物理节点，且磁盘空间足够且集群节点IO性能好，所以选择的并行导出模式为local模式。 Local模式导出数据操作示例如下所示： 登录集群的每个物理节点，创建导出数据文件存放目录“/output_data”，并修改数据文件目录“/output_data”的属主为omm。 以下以IP为192.168.0.11的节点为例，进行操作。 mkdir -p /output_datachown -R omm:dbgrp /output_data 在数据库上创建外表foreign_tpcds_reasons，用于导出数据。 其中设置的导出模式信息如下所示： 由于上一步中创建的导出数据文件存放目录为“/output_data/”。所以设置参数“location”为“file:///output_data/”。 设置导出的数据文件格式信息如下所示： 数据文件格式（format）为CSV。 编码格式（encoding）为UTF-8。 字段分隔符（delimiter）为E'\x20'。 引号字符（quote）为0x1b。 数据文件中空值（null）为没有引号的空字符串。 逃逸字符（escape）为默认值双引号。 数据文件是否包含标题行（header）为默认值false，即导出时数据文件第一行被识别为数据。 根据以上信息，创建的外表foreign_tpcds_reasons如下所示： 123456 openGauss=# CREATE FOREIGN TABLE foreign_tpcds_reasons( r_reason_sk integer not null, r_reason_id char(16) not null, r_reason_desc char(100)) SERVER gsmpp_server OPTIONS (LOCATION 'file:///output_data/', FORMAT 'CSV',ENCODING 'utf8', DELIMITER E'\x20', QUOTE E'\x1b', NULL '') WRITE ONLY; 在数据库中执行数据导出。 1 openGauss=# INSERT INTO foreign_tpcds_reasons SELECT * FROM reasons; 查看导出的数据文件。 数据文件将生成在集群各节点的“/output_data/YYYYMMDD/DN实例名”目录下。其中，“YYYYMMDD”为系统当前日期，“DN实例名”可通过以下语句查询。 1 2 3 4 5 6 7 8 9101112 openGauss=# SELECT node_name,node_host FROM pgxc_node WHERE node_type='D'; node_name | node_host --------------+---------------- dn_6001_6002 | 192.168.0.11 dn_6003_6004 | 192.168.0.11 dn_6005_6006 | 192.168.0.12 dn_6007_6008 | 192.168.0.12 dn_6009_6010 | 192.168.0.13 dn_6011_6012 | 192.168.0.13 dn_6013_6014 | 192.168.0.14 dn_6015_6016 | 192.168.0.14(8 rows) 以IP为192.168.0.11的节点为例，该节点上的DN实例名为“dn_6001_6002”和“dn_6003_6004”，则导出的数据文件存放在该节点“/output_data/20160101/dn_6001_6002”和“/output_data/20160101/dn_6003_6004”目录下。

使用分区表 分区表是把逻辑上的一张表根据某种方案分成几张物理块进行存储。这张逻辑上的表称之为分区表，物理块称之为分区。分区表是一张逻辑表，不存储数据，数据实际是存储在分区上的。分区表和普通表相比具有以下优点： 改善查询性能：对分区对象的查询可以仅搜索自己关心的分区，提高检索效率。 增强可用性：如果分区表的某个分区出现故障，表在其他分区的数据仍然可用。 方便维护：如果分区表的某个分区出现故障，需要修复数据，只修复该分区即可。 GaussDB支持的分区表为范围分区表。 范围分区表：将数据基于范围映射到每一个分区。这个范围是由创建分区表时指定的分区键决定的。分区键经常采用日期，例如将销售数据按照月份进行分区。 父主题： 审视和修改表定义

选择数据类型 高效数据类型，主要包括以下三方面： 尽量使用执行效率比较高的数据类型 一般来说整型数据运算(包括=、＞、＜、≧、≦、≠等常规的比较运算，以及group by)的效率比字符串、浮点数要高。比如某客户场景中对列存表进行点查询，filter条件在一个numeric列上，执行时间为10+s；修改numeric为int类型之后，执行时间缩短为1.8s左右。 尽量使用短字段的数据类型 长度较短的数据类型不仅可以减小数据文件的大小，提升IO性能；同时也可以减小相关计算时的内存消耗，提升计算性能。比如对于整型数据，如果可以用smallint就尽量不用int，如果可以用int就尽量不用bigint。 使用一致的数据类型 表关联列尽量使用相同的数据类型。如果表关联列数据类型不同，数据库必须动态地转化为相同的数据类型进行比较，这种转换会带来一定的性能开销。 父主题： 审视和修改表定义