云服务器内容精选
-
Plan Hint实际调优案例 本节以TPC-DS标准测试的Q24的部分语句为例，在1000X，24DN环境上，说明使用plan hint进行实际调优的过程。示例如下： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 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) netpaid from store_sales ,store_returns ,store ,item ,customer ,customer_address where ss_ticket_number = sr_ticket_number and ss_item_sk = sr_item_sk and ss_customer_sk = c_customer_sk and ss_item_sk = i_item_sk and ss_store_sk = s_store_sk and c_birth_country = upper(ca_country) and s_zip = ca_zip and s_market_id=7 group 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： 图1 语句初始计划 该计划中，第10层算子使用broadcast性能较差，由于第11层算子估算行数为2140，比实际行数严重低估。错误行数估算主要来源于第13层算子的行数低估，根因是第13层hashjoin中，使用store_sales的(ss_ticket_number, ss_item_sk)列和store_returns的(sr_ticket_number, sr_item_sk)列进行关联，由于缺少多列相关性的估算导致行数严重低估。 使用如下的rows hint进行调优后，计划如下，运行时间318s： 1 2 select avg(netpaid) from (select /*+rows(store_sales store_returns * 11270)*/ c_last_name ... 图2 使用rows hint进行调优 时间反而劣化了，原因是第8层hashjoin过慢引起第9层redistribute时间过慢导致，其中第9层redistribute并没有数据倾斜，hashjoin慢的原因是由于第18层redistribute后数据倾斜导致。 经过实际数据查证，customer_address的两个join列的不同值数目较少，使用其进行join容易出现数据倾斜，故把customer_address放到最后进行join。使用如下的hint进行调优后，计划如下，运行时间116s： 1 2 3 4 select avg(netpaid) from (select /*+rows(store_sales store_returns *11270) leading((store_sales store_returns store item customer) customer_address)*/ c_last_name ... 图3 hint调优 发现时间基本花在了第6层redistribute算子上，需要进一步优化。 由于最后一层redistribute包含倾斜，所以时间较长。为了避免倾斜，需要将item表放在最后join，由于item表的join并不能使行数减少。修改hint如下并执行，计划如下，运行时间120s： 1 2 3 4 select avg(netpaid) from (select /*+rows(store_sales store_returns *11270) leading((customer_address (store_sales store_returns store customer) item)) c_last_name ... 图4 修改hint并执行语句 该计划中的redistribute问题并没有解决，因为第22层item表做了broadcast，导致与customer_address表join后的倾斜并没有被消除掉。 增加如下禁止item表做broadcast的hint，使与customer_address join的表做redistribute（也可以进行join表redistribute的hint），计划如下，运行时间105s： 1 2 3 4 5 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 ... 图5 执行计划 发现最后一层使用单层Agg，但行数缩减较多。使用相同的hint，同时结合参数best_agg_plan=3进行双层Agg调优，最终计划如下图所示，运行时间94s，完成调优。 图6 最终调优计划 如果有统计信息变更引起的查询劣化，可以考虑用plan hint来调整到之前的查询计划。这里以TPCH-Q17为例，在收集default_statistics_target设置为–2的统计信息之后，计划相比于默认统计信息发生劣化。 默认统计信息（default_statistics_target设置为100）的计划如下： 图7 默认统计信息 统计信息变更（default_statistics_target设置为–2）的计划如下： 图8 统计信息变更 经过对比，劣化的原因主要为lineitem和part表join时stream类型由BroadCast变更为Redistribute导致。可以对语句进行stream方式的hint来调整到之前的计划，例如： 图9 调整语句 父主题： 使用Plan Hint进行调优
-
语法格式 1 wlmrule("time_limit,max_execute_time,max_iops") 本参数仅在enable_thread_pool=on时对非sysadmin/monitoradmin用户执行的select类型的语句生效。 time_limit：SQL语句被标记为慢SQL的执行时长，取值为0-INT_MAX，CN和DN上均可生效。 max_execute_time：SQL语句的最大执行时间，执行时间超过该时长后被强制cancel退出，取值为0-INT_MAX，仅在DN上生效。当max_execute_time小于或等于time_limit时，该规则不生效。 max_iops：SQL语句被标记为慢SQL后最大iops上限，仅在use_workload_manager=on时生效。iops限制采用逻辑IO管控，iops定义请参考io_control_unit定义。取值范围为：Low、Medium、High、None、0-INT_MAX，仅在DN上生效。
-
语法格式 1 2 3 4 predpush_same_level(src, dest) predpush_same_level(src1 src2 ..., dest) [no] nestloop_index([@queryblock] dest[, index_list]) -- 索引方式 [no] nestloop_index([@queryblock] dest[,(src1 src2 ...)]) -- 表名方式 predpush_same_level参数仅在rewrite_rule中的predpushforce选项打开时生效。 nestloop_index对rewrite_rule不做要求。
-
参数说明 @queryblock请参见指定Hint所处于的查询块Queryblock，可省略，表示在当前查询块生效，该hint只在指定为最外层的queryblock时才会生效。 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、partition_iterator_elimination、partition_page_estimation、enable_functional_dependency、var_eq_const_selectivity、enable_inner_unique_opt、enable_force_smp、enable_invisible_indexes 整型类： query_dop，multi_insert_min_rows 浮点类： 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 设置不在白名单中的参数，参数取值不合法，或hint语法错误时，不会影响查询执行的正确性。使用explain(verbose on)执行可以看到hint解析错误的报错提示。 GUC参数的hint只在最外层查询生效，子查询内的GUC参数hint不生效。 视图定义内的GUC参数hint不生效。 CREATE TABLE ... AS ...查询最外层的GUC参数hint可以生效。
-
示例 创建表t1、t2、t3： 1 2 3 create table t1(a1 int,b1 int,c1 int,d1 int); create table t2(a2 int,b2 int,c2 int,d2 int); create table t3(a3 int,b3 int,c3 int,d3 int); 原语句为： 1 explain select * from t3, (select a1,b2,c1,d2 from t1,t2 where t1.a1=t2.a2) s1 where t3.b3=s1.b2; 上述查询中，可以使用以下两种方式禁止子查询s1进行提升： 方式一： 1 explain select /*+ no merge(s1) */ * from t3, (select a1,b2,c1,d2 from t1,t2 where t1.a1=t2.a2) s1 where t3.b3=s1.b2; 方式二： 1 explain select * from t3, (select /*+ no merge */ a1,b2,c1,d2 from t1,t2 where t1.a1=t2.a2) s1 where t3.b3=s1.b2; 提升后效果：
-
Plan Hint实际调优案例 本节以TPC-DS标准测试的Q24的部分语句为例，在1000X，24DN环境上，说明使用plan hint进行实际调优的过程。示例如下： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 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) netpaid from store_sales ,store_returns ,store ,item ,customer ,customer_address where ss_ticket_number = sr_ticket_number and ss_item_sk = sr_item_sk and ss_customer_sk = c_customer_sk and ss_item_sk = i_item_sk and ss_store_sk = s_store_sk and c_birth_country = upper(ca_country) and s_zip = ca_zip and s_market_id=7 group 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： 1 2 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： 1 2 3 4 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： 1 2 3 4 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： 1 2 3 4 5 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进行调优
-
Hint使用准备 为了方便了解hint的使用场景，手册提供了所有查询改写hint的应用示例，请参见Hint使用说明，相关建表语句和环境准备如下： 会话设置： SET client_encoding = 'UTF8'; CREATE SCHEMA rewrite_rule_test; SET current_schema = rewrite_rule_test; SET enable_codegen= off;
-
查询改写Hint列表 表1 查询改写支持的hint列表 序号 Hint名称 描述 1 EXPAND_SUBLINK_HAVING 允许HAVING子句中的子链接提升。 2 NO_EXPAND_SUBLINK_HAVING 禁止HAVING子句中的子链接提升。 3 EXPAND_SUBLINK 允许对ANY/EXISTS类型子链接进行提升。 4 NO_EXPAND_SUBLINK 禁止对ANY/EXISTS类型子链接进行提升。 5 EXPAND_SUBLINK_TARGET 允许对TargetList中的子链接进行提升。 6 NO_EXPAND_SUBLINK_TARGET 禁止对TargetList中的子链接进行提升。 7 USE_MAGIC_SET 从主查询下推条件到子查询，先针对子查询的关联字段进行分组聚集，再和主查询进行关联，减少相关子链接的重复扫描，提升查询效率。 8 NO_USE_MAGIC_SET 禁止从主查询下推条件到子查询，将带有聚集算子的子查询提前和主查询进行关联。 9 EXPAND_SUBLINK_UNIQUE_CHECK 允许对无agg的子链接进行提升，子链接提升需要保证对于每个条件只有一行输出。 10 NO_EXPAND_SUBLINK_UNIQUE_CHECK 禁止对无agg的子链接进行提升。 11 NO_SUBLINK_DISABLE_REPLICATED 允许带有复制表的fast query shipping或者Stream场景的表达式子链接提升。 12 SUBLINK_DISABLE_REPLICATED 禁止带有复制表的fast query shipping或者Stream场景的表达式子链接提升。 13 NO_SUBLINK_DISABLE_EXPR 允许对表达式类型的子链接进行提升。 14 SUBLINK_DISABLE_EXPR 禁止对表达式类型的子链接进行提升。 15 ENABLE_SUBLINK_ENHANCED 允许子链接提升增强，支持对OR表达式等相关或非相关子链接提升。 16 NO_ENABLE_SUBLINK_ENHANCED 禁用子链接提升增强，禁止对OR表达式等相关或非相关子链接提升。 17 PARTIAL_PUSH Stream场景支持对listagg和arrayagg添加gather算子。 18 NO_PARTIAL_PUSH Stream场景禁止对listagg和arrayagg添加gather算子。 19 REDUCE_ORDER_BY 消减冗余的ORDER BY，外层查询对内层查询结果无排序要求时，可以减少不必要的ORDER BY提升查询效率。 20 NO_REDUCE_ORDER_BY 禁止消减不必要的ORDER BY。 21 REMOVE_NOT_NULL 消减不必要的NOT NULL条件，当列属性为NOT NULL时，可以消减查询条件中的IS NOT NULL判断。 22 NO_REMOVE_NOT_NULL 禁止消减IS NOT NULL条件判断。 23 LAZY_AGG 子查询与外层查询存在同样的GROUP BY条件，两层聚集运算可能导致查询效率低下，消除子查询中的聚集运算，以此提高查询效率。 24 NO_LAZY_AGG 禁用消除子查询中的聚集运算规则。 25 EXPAND_SUBQUERY 子查询提升，将子查询提升与上层做JOIN连接，优化查询效率。 26 NO_EXPAND_SUBQUERY 禁用子查询提升。 27 PUSHDOWN_HAVING 下推HAVING条件表达式。 28 NO_PUSHDOWN_HAVING 禁止下推HAVING表达式。 29 INLIST_TO_JOIN 控制使用inlist-to-join对SQL进行改写。 30 NO_INLIST_TO_JOIN 控制禁止使用inlist-to-join对SQL进行改写。 31 ROWNUM_PUSHDOWN 允许行号下推。 32 NO_ROWNUM_PUSHDOWN 禁止行号下推。 33 WINDOWAGG_PUSHDOWN 允许父查询中窗口函数的过滤条件下推到子查询。 34 NO_WINDOWAGG_PUSHDOWN 禁止父查询中窗口函数的过滤条件下推到子查询。
-
功能描述 优化器支持一系列查询改写规则，可以对SQL语句进行等价的逻辑改写，从而生成更好的执行计划。但在一些场景下，用户并不希望改写SQL语句、或者优化器的改写会导致计划跳变，对于这些特定的场景，需要能够使用hint对改写规则进行控制，让优化器按照特定的方式进行改写。目前数据库支持对ANY/EXISTS的子链接、简单子查询、消减ORDER BY、HAVING子句下推、延迟聚合等多种场景的SQL进行hint控制，具体请参见：Hint使用说明。 部分查询改写规则同时受查询改写的hint和GUC参数控制，通常查询改写的hint优先级高于GUC参数控制，涉及到受GUC参数控制的改写规则会在Hint使用说明相关章节进行描述。 每条查询改写规则受一对互斥的hint控制，如：子查询展开的规则同时受EXPAND_SUBQUERY和NO_EXPAND_SUBQUERY控制，其中，EXPAND_SUBQUERY Hint表示允许应用该规则对SQL进行改写，NO_EXPAND_SUBQUERY表示禁止使用该规则对SQL进行改写。且当同一个查询块（queryblock）中同时存在两个互斥的hint时，以获取的首个hint为准，例如：/*+ EXPAND_SUBQUERY NO_EXPAND_SUBQUERY */，则EXPAND_SUBQUERY Hint生效。 查询改写的hint允许重复，但对于重复的hint数据库只会使用第一个，对于其他未使用的hint则会报"unused hint" Warning提示。例如：/*+ EXPAND_SUBLINK EXPAND_SUBLINK */，由于数据库只使用第一个EXPAND_SUBLINK hint，所以仍然会报"unused hint" Warning提示。
-
参数说明 relname为查询中表table的名字，表有别名时，需要优先使用别名alias，此时relname=alias。当表名中有特殊符号，比如“@”、“.”时，relname需要用""括起来，以避免和查询块和schema名的声明重合。比如表名relnametest@1，需要写做 "relnametest@1"。 schema为表所处的schema，可缺省，缺省时Hint不区分schema对relname进行查找。 queryblock为表所处的queryblock，可缺省，缺省时Hint不区分queryblock对relname进行查找。
-
参数说明 relname为查询中表table的名字，表有别名时，需要优先使用别名alias，此时relname=alias。当表名中有特殊符号，比如“@”、“.”时，relname需要用""括起来，以避免和查询块和schema名的声明重合。比如表名relnametest@1，需要写做 "relnametest@1"。 schema为表所处的schema，可缺省，缺省时Hint不区分schema对relname进行查找。 queryblock为表所处的queryblock，可缺省，缺省时Hint不区分queryblock对relname进行查找。
-
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进行调优
-
示例 gaussdb=# deallocate all; DEALLOCATE ALL gaussdb=# prepare p1 as insert /*+ no_gpc*/ into t1 select c1,c2 from t2 where c1=$1; PREPARE gaussdb=# execute p1(3); INSERT 0 1 gaussdb=# select * from dbe_perf.global_plancache_status where schema_name='public' order by 1,2; nodename | query | refcount | valid | databaseid | schema_name | params_num | func_id | pkg_id | stmt_id ----------+-------+----------+-------+------------+-------------+------------+---------+--------+--------- (0 rows) dbe_perf.global_plancache_status视图中无结果即没有计划被全局缓存。
-
语法格式 1 wlmrule("time_limit,max_execute_time,max_iops") 本参数仅在enable_thread_pool=on时对非sysadmin/monitoradmin用户执行的select类型的语句生效。 time_limit：SQL语句被标记为慢SQL的执行时长，取值为0-INT_MAX。 max_execute_time：SQL语句的最大执行时间，执行时间超过该时长后被强制cancel退出，取值为0-INT_MAX。当max_execute_time小于或等于time_limit时，该规则不生效。 max_iops：SQL语句被标记为慢SQL后最大iops上限，仅在use_workload_manager=on时生效。iops限制采用逻辑IO管控，iops定义请参考io_control_unit定义。取值范围为：Low，Medium，High，None，0-INT_MAX。
-
Plan Hint实际调优案例 本节以TPC-DS标准测试的Q24的部分语句为例，在1000X，24DN环境上，说明使用plan hint进行实际调优的过程。示例如下： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 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) netpaid from store_sales ,store_returns ,store ,item ,customer ,customer_address where ss_ticket_number = sr_ticket_number and ss_item_sk = sr_item_sk and ss_customer_sk = c_customer_sk and ss_item_sk = i_item_sk and ss_store_sk = s_store_sk and c_birth_country = upper(ca_country) and s_zip = ca_zip and s_market_id=7 group 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： 1 2 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： 1 2 3 4 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： 1 2 3 4 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： 1 2 3 4 5 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进行调优
更多精彩内容
CDN加速
GaussDB
文字转换成语音
免费的服务器
如何创建网站
域名网站购买
私有云桌面
云主机哪个好
域名怎么备案
手机云电脑
SSL证书申请
云点播服务器
免费OCR是什么
电脑云桌面
域名备案怎么弄
语音转文字
文字图片识别
云桌面是什么
网址安全检测
网站建设搭建
国外CDN加速
SSL免费证书申请
短信批量发送
图片OCR识别
云数据库MySQL
个人域名购买
录音转文字
扫描图片识别文字
OCR图片识别
行驶证识别
虚拟电话号码
电话呼叫中心软件
怎么制作一个网站
Email注册网站
华为VNC
图像文字识别
企业网站制作
个人网站搭建
华为云计算
免费租用云托管
云桌面云服务器
ocr文字识别免费版
HTTPS证书申请
图片文字识别转换
国外域名注册商
使用免费虚拟主机
云电脑主机多少钱
鲲鹏云手机
短信验证码平台
OCR图片文字识别
SSL证书是什么
申请企业邮箱步骤
免费的企业用邮箱
云免流搭建教程
域名价格
