华为云用户手册

示例 强制使用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 -- CS tore 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。 使用一致的数据类型 表关联列尽量使用相同的数据类型。如果表关联列数据类型不同，数据库必须动态地转化为相同的数据类型进行比较，这种转换会带来一定的性能开销。 父主题： 审视和修改表定义

选择分布列 Hash分布表的分布列选取至关重要，需要满足以下原则： 列值应比较离散，以便数据能够均匀分布到各个DN。例如，考虑选择表的主键为分布列，如在人员信息表中选择身份证号码为分布列。 在满足第一条原则的情况下尽量不要选取存在常量filter的列。例如，表dwcjk相关的部分查询中出现dwcjk的列zqdh存在常量的约束(例如zqdh=’000001’)，那么就应当尽量不用zqdh做分布列。 在满足前两条原则的情况，考虑选择查询中的连接条件为分布列，以便Join任务能够下推到DN中执行，且减少DN之间的通信数据量。 对于Hash分表策略，如果分布列选择不当，可能导致数据倾斜，查询时出现部分DN的I/O短板，从而影响整体查询性能。因此在采用Hash分表策略之后需对表的数据进行数据倾斜性检查，以确保数据在各个DN上是均匀分布的。可以使用以下SQL检查数据倾斜性 12345 select xc_node_id, count(1) from tablename group by xc_node_id order by xc_node_id desc; 其中xc_node_id对应DN，一般来说，不同DN的数据量相差5%以上即可视为倾斜，如果相差10%以上就必须要调整分布列。 GaussDB支持多分布列特性，可以更好地满足数据分布的均匀性要求。 Range/List分布表的分布列由用户根据实际需要进行选择。除了需选择合适的分布列，还需要注意分布规则对数据分布的影响。 父主题： 审视和修改表定义

选择分布方式 复制表（Replication）方式将表中的全量数据在集群的每一个DN实例上保留一份。主要适用于记录集较小的表。这种存储方式的优点是每个DN上都有该表的全量数据，在join操作中可以避免数据重分布操作，从而减小网络开销，同时减少了plan segment(每个plan segment都会起对应的线程)；缺点是每个DN都保留了表的完整数据，造成数据的冗余。一般情况下只有较小的维度表才会定义为Replication表。 哈希（Hash）表将表中某一个或几个字段进行hash运算后，生成对应的hash值，根据DN实例与哈希值的映射关系获得该元组的目标存储位置。对于Hash分布表，在读/写数据时可以利用各个节点的IO资源，大大提升表的读/写速度。一般情况下大表定义为Hash表。 范围（Range）和列表（List）分布是由用户自定义的分布策略，根据分布列的取值落入满足一定范围或者具体值的对应目标DN，这两种分布方式便于用户灵活地进行数据管理，但对用户本身的数据抽象能力有一定的要求。 策略 描述 适用场景 Hash 表数据通过hash方式散列到集群中的所有DN实例上。 数据量较大的事实表。 Replication 集群中每一个DN实例上都有一份全量表数据。 小表、维度表。 Range 表数据对指定列按照范围进行映射，分布到对应DN。 用户需要自定义分布规则的场景。 List 表数据对指定列按照具体值进行映射，分布到对应DN。 用户需要自定义分布规则的场景。 如图1所示，复制表如图中的表T1，哈希表如图中的表T2。 图1 复制表和哈希表 父主题： 审视和修改表定义

背景信息 ANALYZE语句可收集与数据库中表内容相关的统计信息，统计结果存储在系统表PG_STATISTIC中。查询优化器会使用这些统计数据，以生成最有效的执行计划。 建议在执行了大批量插入/删除操作后，例行对表或全库执行ANALYZE语句更新统计信息。目前默认收集统计信息的采样比例是30000行（即：guc参数default_statistics_target默认设置为100），如果表的总行数超过一定行数（大于1600000），建议设置guc参数default_statistics_target为-2，即按2%收集样本估算统计信息。 对于在批处理脚本或者存储过程中生成的中间表，也需要在完成数据生成之后显式的调用ANALYZE。 对于表中多个列有相关性且查询中有同时基于这些列的条件或分组操作的情况，可尝试收集多列统计信息（当前特性是实验室特性，使用时请联系华为工程师提供技术支持），以便查询优化器可以更准确地估算行数，并生成更有效的执行计划。

审视和修改表定义概述 在分布式框架下，数据分布在各个DN上。一个或者几个DN的数据存在一块物理存储设备上，好的表定义至少需要达到以下几个目标： 表数据均匀分布在各个DN上，以防止单个DN对应的存储设备空间不足造成集群有效容量下降。选择合适分布列，避免数据分布倾斜可以实现该点。 表Scan压力均匀分散在各个DN上，以避免单DN的Scan压力过大，形成Scan的单节点瓶颈。分布列不选择基表上等值filter中的列可以实现该点。 减少扫描数据量。通过分区的剪枝机制可以实现该点。 尽量极少随机IO。通过聚簇/局部聚簇可以实现该点。 尽量避免数据shuffle，减小网络压力。通过选择join-condition或者group by列为分布列可以最大程度的实现这点。 从上述描述来看表定义中最重要的一点是分布列的选择。创建表定义一般遵循图1所示流程。表定义在数据库设计阶段创建，在SQL调优过程中进行审视和修改。 图1 表定义流程 父主题： 审视和修改表定义

选择存储模型 进行数据库设计时，表设计上的一些关键项将严重影响后续整库的查询性能。表设计对数据存储也有影响：好的表设计能够减少I/O操作及最小化内存使用，进而提升查询性能。 表的存储模型选择是表定义的第一步。客户业务属性是表的存储模型的决定性因素，依据下面表格选择适合当前业务的存储模型。 存储模型 适用场景 行存 点查询(返回记录少，基于索引的简单查询)。 增删改比较多的场景。 列存 统计分析类查询 (group , join多的场景)。 父主题： 审视和修改表定义

调优手段之统计信息 GaussDB优化器是典型的基于代价的优化 (Cost-Based Optimization，简称CBO)。在这种优化器模型下，数据库根据表的元组数、字段宽度、NULL记录比率、distinct值、MCV值、HB值等表的特征值，以及一定的代价计算模型，计算出每一个执行步骤的不同执行方式的输出元组数和执行代价(cost)，进而选出整体执行代价最小/首元组返回代价最小的执行方式进行执行。这些特征值就是统计信息。从上面描述可以看出统计信息是查询优化的核心输入，准确的统计信息将帮助规划器选择最合适的查询规划，一般来说我们通过analyze语法收集整个表或者表的若干个字段的统计信息，周期性地运行ANALYZE，或者在对表的大部分内容做了更改之后马上运行它是个好习惯。

调优手段之GUC参数 查询优化的主要目的是为查询语句选择高效的执行方式。 如下SQL语句: 12 select count(1) from customer inner join store_sales on (ss_customer_sk = c_customer_sk); 在执行customer inner join store_sales的时候，GaussDB支持Nested Loop、Merge Join和Hash Join三种不同的Join方式。优化器会根据表customer和表store_sales的统计信息估算结果集的大小以及每种join方式的执行代价，然后对比选出执行代价最小的执行计划。 正如前面所说，执行代价计算都是基于一定的模型和统计信息进行估算，当因为某些原因代价估算不能反映真实的cost的时候，我们就需要通过guc参数设置的方式让执行计划倾向更优规划。

操作步骤 收集SQL中涉及到的所有表的统计信息。在数据库中，统计信息是规划器生成计划的源数据。没有收集统计信息或者统计信息陈旧往往会造成执行计划严重劣化，从而导致性能问题。从经验数据来看，10%左右性能问题是因为没有收集统计信息。具体请参见更新统计信息。 通过查看执行计划来查找原因。如果SQL长时间运行未结束，通过EXPLAIN命令查看执行计划，进行初步定位。如果SQL可以运行出来，则推荐使用EXPLAIN ANALYZE或EXPLAIN PERFORMANCE查看执行计划及实际运行情况，以便更精准地定位问题原因。有关执行计划的详细介绍请参见SQL执行计划介绍。 审视和修改表定义。 针对EXPLAIN或EXPLAIN PERFORMANCE信息，定位SQL慢的具体原因以及改进措施，具体参见典型SQL调优点。 通常情况下，有些SQL语句可以通过查询重写转换成等价的，或特定场景下等价的语句。重写后的语句比原语句更简单，且可以简化某些执行步骤达到提升性能的目的。查询重写方法在各个数据库中基本是通用的。经验总结：SQL语句改写规则介绍了几种常用的通过改写SQL进行调优的方法。

执行计划显示格式 GaussDB对执行计划提供了normal、pretty、summary、run四种显示格式： normal：代表使用默认的打印格式。图1中即为此显示格式。 pretty：代表使用GaussDB改进后的新显示格式。新的格式层次清晰，计划包含了plan node id，性能分析简单直接。如图2。 summary：是在pretty的基础上增加了对打印信息的分析。 run：在summary的基础上，将统计的信息输出到csv格式的文件中，以便于进一步分析。

执行计划显示信息 除了设置不同的执行计划显示格式外，还可以通过不同的EXPLAIN用法，显示不同详细程度的执行计划信息。常见有如下几种，关于更多用法请参见EXPLAIN语法说明。 EXPLAIN statement： 只生成执行计划，不实际执行。其中statement代表SQL语句。 EXPLAIN ANALYZE statement：生成执行计划，进行执行，并显示执行的概要信息。显示中加入了实际的运行时间统计，包括在每个规划节点内部花掉的总时间(以毫秒计)和它实际返回的行数。 EXPLAIN PERFORMANCE statement：生成执行计划，进行执行，并显示执行期间的全部信息。 为了测量运行时在执行计划中每个节点的开销，EXPLAIN ANALYZE或EXPLAIN PERFORMANCE会在当前查询执行上增加性能分析的开销。在一个查询上运行EXPLAIN ANALYZE或EXPLAIN PERFORMANCE有时会比普通查询明显的花费更多的时间。超支的数量依赖于查询的本质和使用的平台。 因此，当定位SQL运行慢问题时，如果SQL长时间运行未结束，建议通过EXPLAIN命令查看执行计划，进行初步定位。如果SQL可以运行出来，则推荐使用EXPLAIN ANALYZE或EXPLAIN PERFORMANCE查看执行计划及其实际的运行信息，以便更精准地定位问题原因。