云服务器内容精选

  • 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进行调优
  • 示例 强制使用Custom Plan: 1 2 3 4 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: 1 2 3 deallocate p; prepare p as select /*+ use_gplan */ * from t where a = $1; explain execute p(1); 计划如下,可以看到过滤条件为待填充的入参,即此计划为Generic Plan。
  • 语法格式 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不做要求。
  • 参数说明 join_table_list为表示表join顺序的hint字符串,可以包含当前层的任意个表(别名),或对于子查询提升的场景,也可以包含子查询的hint别名,同时任意表可以使用括号指定优先级,表之间使用空格分隔。 @queryblock请参见指定Hint所处于的查询块Queryblock,可省略,表示在当前查询块生效。 表只能用单个字符串表示,不能带schema。 表如果存在别名,需要优先使用别名来表示该表。
  • 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提示。
  • 语法格式 1 2 3 4 predpush_same_level([@queryblock] src, dest) predpush_same_level([@queryblock] 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不做要求。
  • 建议 推荐使用两个表*的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。
  • 参数说明 @queryblock请参见指定Hint所处于的查询块Queryblock,可省略,表示在当前查询块生效。 “#”、“+”、“-”、“*”,进行行数估算hint的四种操作符号。#表示直接使用后面的行数进行hint。“+”、“-”、“*”表示对原来估算的行数进行加、减、乘操作,运算后的行数最小值为1行。table_list为hint对应的单表或多表join结果集,与Join方式的Hint中table_list相同。
  • 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数据库只会使用第一个,对于其他未使用的hint则会报"unused hint" Warning提示。例如:/*+ expand_sublink expand_sublink */由于数据库只使用第一个expand_sublink hint,所以仍然会报"unused hint" Warning提示。 子链接提升后hint失效 子链接提升后的hint失效,会给出提示。通常出现在子链接中存在多个表连接的场景。提升后,子链接中的多个表不再作为一个整体出现在join中。 列类型不支持重分布 对于skew hint来说,目的是为了进行重分布时的调优,所以当hint列的类型不支持重分布时,hint将无效。 hint未被使用 非等值join使用hashjoin hint或mergejoin hint。 不包含索引的表使用indexscan hint或indexonlyscan hint。 不包含全局二级索引的表使用gsi hint。 通常只有在索引列上使用过滤条件才会生成相应的索引路径,全表扫描将不会使用索引,因此使用indexscan hint、indexonlyscan hint或gsi hint将不会使用。 indexonlyscan只有输出列仅包含索引列才会使用,否则指定时hint不会被使用。 gsi只有查询能够下推至全局二级索引时才会使用,否则不会被使用。 多个表存在等值连接时,仅尝试有等值连接条件的表连接,此时没有关联条件的表之间的路径将不会生成,所以指定相应的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视图中无结果即没有计划被全局缓存。
  • 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数据库只会使用第一个,对于其他未使用的hint则会报"unused hint" Warning提示。例如:/*+ expand_sublink expand_sublink */由于数据库只使用第一个expand_sublink Hint,所以仍然会报"unused hint" Warning提示。 子链接提升后hint失效 子链接提升后的hint失效,会给出提示。通常出现在子链接中存在多个表连接的场景。提升后,子链接中的多个表不再作为一个整体出现在join中。 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)不会被使用。 如果子链接未被提升,则blockname hint不会被使用。 父主题: 使用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上生效。
  • 示例 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视图中无结果即没有计划被全局缓存。