华为云用户手册

注意事项 skew hint仅在需要重分布且指定的倾斜信息与查询执行过程中的重分布信息相匹配时才会被使用。 skew hint受GUC参数skew_option限制，如果参数处于关闭状态，则无法进行skew hint倾斜调优。 skew hint目前仅处理普通表和子查询类型的表关系，支持基表hint、子查询hint、with as子句hint。对于子查询，无论提升与否都支持在skew hint中使用，这点与其它hint不一样。 对于倾斜表，如果定义了别名，则在hint中必须使用别名。 对于倾斜列，在不产生歧义的情况下，可以使用原名也可以使用别名。skew hint的column不支持表达式，如果需要指定采用分布键为表达式的重分布存在倾斜，需要将重分布键指定为新的列，以新的列进行hint。 对于倾斜值，个数需为列数的整数倍并按列的顺序进行组合，组合的个数不能超过10个。如果各倾斜列的倾斜值的个数不一样，为了满足按列组合，值可以重复指定。如，表t1的c1和c2存在倾斜，c1列的倾斜值只有a1，而c2列的倾斜有b1和b2，则skew hint如下：skew(t1 (c1 c2) ((a1 b1)(a1 b2)))。例中(a1 b1)为一个值组合，NULL可以作为倾斜值出现，每个hint中的值组合不超过十个， 且需为列的整数倍。 在Join的重分布优化中，skew hint中的value不可缺省，在HashAgg中可以缺省。 对于表、列、值中若指定多个，则同类间需以空格分离。 对于倾斜值，不支持在hint中进行类型强转；对于string类型，需要使用单引号。

参数说明 block_name表示语句块的block_name，详细说明请参考block_name。 table表示存在倾斜的单个表名。 表的语法格式如下： [schema.]table[@block_name] 表名可以带schema，也可以带所在子查询语句块提升前的block_name。子查询语句块在优化器进行优化重写时发生提升，则该block_name会与leading中block_name不同。 表如果存在别名，优先使用别名来表示该表。 join_rel表示参与join的两个或多个表，如（t1 t2）表示t1和t2join后的结果存在倾斜。 column表示倾斜表中存在倾斜的一个或多个列。 value表示倾斜的列中存在倾斜的一个或多个值。

参数说明 block_name表示语句块的block_name，详细说明请参考block_name。 table表示为该子链接块hint的别名的名称。 表的语法格式如下： [schema.]table[@block_name] 表名可以带schema，也可以带所在子查询语句块提升前的block_name。子查询语句块在优化器进行优化重写时发生提升，则该block_name会与leading中block_name不同。 表如果存在别名，优先使用别名来表示该表。

注意事项 block_name hint仅在对应的子链接块提升时才会被上层查询使用。目前支持的子链接提升包括IN子链接提升、EXISTS子链接提升和包含Agg等值相关子链接提升。该hint通常会和前面章节提到的hint联合使用。 对于FROM关键字后的子查询，则需要使用子查询的别名进行hint，block_name hint不会被用到。 如果子链接中含有多个表，则提升后这些表可与外层表以任意优化顺序连接，hint也不会被用到。

参数说明 no表示hint的scan方式不使用。 block_name表示语句块的block_name，详细说明请参考block_name。 table表示hint指定的表，只能指定一个表，如果表存在别名应优先使用别名进行hint。 表的语法格式如下： [schema.]table[@block_name] 表名可以带schema，也可以带所在子查询语句块提升前的block_name。子查询语句块在优化器进行优化重写时发生提升，则该block_name会与leading中block_name不同。 表如果存在别名，优先使用别名来表示该表。 index表示使用indexscan或indexonlyscan的hint时，指定的索引名称，当前只能指定一个。 对于indexscan或indexonlyscan，只有hint的索引属于hint的表时，才能使用该hint。 scan hint支持在行列存表、hdfs内外表、obs表、子查询表上指定。对于hdfs内表，由主表和delta表组成，delta表对用户不可见，故hint仅作用在主表上。 指定indexscan可生效indexscan或indexonlyscan，indexscan或indexonlyscan也可同时出现。当indexscan和indexonlyscan hint同时出现，优先生效indexonlyscan。

示例 对示例中原语句使用如下hint： 1 2 explain select /*+ no redistribute(store_sales store_returns item store) leading(((store_sales store_returns item store) customer)) */ i_product_name product_name ... 原计划中，(store_sales store_returns item store)和customer做join时，前者做了重分布，此hint表示禁止前者混合表做重分布，但仍然保持join顺序，则生成计划如下所示：

建议 通常优化器会根据统计信息选择一组不倾斜的分布键进行数据重分布。当默认选择的分布键有倾斜时，可以手动指定重分布的列，避免数据倾斜。 在选择分布键的时候，通常要根据数据分布特征选取一组distinct值比较高的列作为分布列，这样可以保证重分布后，数据均匀的分布到各个DN。 在编写好hint后，可以通过explain verbose+SQL打印执行计划，查看指定的分布键是否有效，如果指定的分布键无效会有warning提示。

参数说明 no表示hint的stream方式不使用，当指定AGG分布列的hint时指定no关键字无效。 block_name表示语句块的block_name，详细说明请参考block_name。 table_list为进行stream操作的单表或多表join结果集，见参数说明。 当指定分布列的hint时，*为固定写法，不支持指定表名。 columns指定group by子句中的一个或者多个列，没有group by子句也可以指定distinct子句中的列。 指定的分布列，需要用group by或distinct中的列序号或列名来表示，count（distinct）中的列只能通过列名指定。 对于多层的查询，可以在每层指定对应层的分布列hint，只在当前层生效。 指定的count(distinct)列仅针对生成双层hashagg的计划时才生效，否则指定的分布列无效。 指定了分布列，如果优化器估算后发现不需要重分布，则指定的分布列无效。

建议 推荐使用两个表*的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。

参数说明 block_name表示语句块的block_name，详细说明请参考block_name。 #,+,-,*，进行行数估算hint的四种操作符号。#表示直接使用后面的行数进行hint。+,-,*表示对原来估算的行数进行加、减、乘操作，运算后的行数最小值为1行。table_list为hint对应的单表或多表join结果集，与Join方式的Hint中table_list相同。 const可以是任意非负数，支持科学计数法。

语法格式 单层圆括号()，仅指定join顺序，不指定内外表顺序。 1 2 leading(join_table_list) leading(@block_name join_table_list) 双层圆括号(())，同时指定join顺序和内外表顺序，内外表顺序仅在最外层生效。 1 2 leading((join_table_list)) leading(@block_name (join_table_list))

参数说明 join_table_list 为表示表join顺序的hint字符串，可以包含当前层的任意个表（别名），或对于子查询提升的场景，也可以包含子查询的hint别名，同时任意表可以使用括号指定优先级，表之间使用空格分隔。 join table list中指定的表需要满足以下要求，否则会报语义错误： list中的表必须在当前层或提升的子查询中存在。 list中的表在当前层或提升的子查询中必须是唯一的。如果不唯一，需要使用不同的别名进行区分。 同一个表只能在list里出现一次。 如果表存在别名，则list中的表需要使用别名。 表的语法格式如下： [schema.]table[@block_name] 表名可以带schema，也可以带所在子查询语句块提升前的block_name。子查询语句块在优化器进行优化重写时发生提升，则该block_name会与leading中block_name不同。 表如果存在别名，优先使用别名来表示该表。

存储层数据倾斜 GaussDB (DWS)数据库中，数据分布存储在各个DN上，通过分布式执行提高查询的效率。但是，如果数据分布存在倾斜，则会导致分布式执行某些DN成为瓶颈，影响查询性能。这种情况通常是由于分布列选择不合理，可以通过调整分布列的方式解决。 例如下例： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 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 9 10 11 12 13 14 15 16 17 18 19 20 21 22 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 9 10 11 12 13 14 15 16 17 18 19 20 21 22 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视图，可以更加高效的查询各表的数据倾斜情况。

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

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

不支持下推的函数 首先介绍函数的易变性。在GaussDB(DWS)中共分三种形态： 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如果出现CTE中，也不下推。因为这种场景下下推可能出现结果错误。 对于用户自定义函数，可以在创建函数的时候指定provolatile和proshippable属性的值，详细请参考CREATE FUNCTION。 对于函数不能下推的场景： 如果是系统函数，建议根据业务等价替换这个函数。 如果是自定义函数，建议分析客户业务场景，看函数的provolatile和proshippable属性定义是否正确。

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

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

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

资源消耗 表3 资源消耗 类别 详细分类 说明 CPU 谓词列管理 自动管理谓词，仅对查询中使用的列收集统计信息。 手动屏蔽非谓词列，可手动设置哪些列不收集统计信息。 超长列统计 可截断的数据类型，仅收取前1024字符计算统计信息。 IO 默认采集3W条样本 与表大小无关，与列数，分区数，小CU数有关。 内存 Buffer占用 最多只占用cstore buffer中的一个槽位。 内存零拷贝 从buffer取出样本后，直接进行统计信息计算，无需组织成tuple再传递。 内存自适应 可配置为内存不足时自动转为使用临时表采样。动态采样为防止查询触发建临时表，不会自适应。 通过GUC参数analyze_stats_mode设置。 内存的大小 控制ANALYZE时最大使用内存，超过后或下盘或自动减少样本。 通过GUC参数maintenance_work_mem设置。 锁 四级锁 normal模式，分布式申请四级锁。与增删改不冲突，与DDL，VACUUM，ANALYZE，REINDEX冲突。 一级锁 light模式，仅本地一级锁。仅与DDL冲突。

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

基本规则 表1 统计信息收集相关基础功能 功能 介绍 特点 约束 手动采样 作业中修改大量数据后，手动执行ANALYZE normal模式，统计信息存系统表，全局共享。四级锁，同一张表不能并发。 light模式，统计信息存内存，全局共享。一级锁，同一张表可以并发。 force模式，在锁定统计信息情况下，也可以强制采样，行为与normal一致。 语法：ANALYZE tablename; ANALYZE (light|force) tablename; - 轮询采样 后台线程，根据阈值 轮询维护统计信息 仅支持normal模式，统计信息存系统表，共享。四级锁，同一张表不能并发 相关GUC参数： autovacuum autovacuum_mode autovacuum_analyze_threshold autovacuum_analyze_scale_factor 异步轮询触发 动态采样 查询解析时，根据阈值，用几十秒的代价 实时维护统计信息 normal模式，统计信息存系统表，全局共享。四级锁，同一张表不能并发 light模式，统计信息存内存，全局共享。一级锁，同一张表可以并发 相关GUC参数： autoanalyze autoanalyze_mode 随查询实时触发 轻量化时依赖轮询采样进行持久化 强制采样 SQL中通过hint，强制每次查询都收集统计信息 用于数据特征敏感场景，确保查询时统计信息实时最新。 用法：select /*+ lightanalyze (t1 1) */ from t1; 1：强制采样，0：禁止采样 需要改SQL 分区统计信息 按分区收集，仅收增量，自动合并全局信息 用于超大分区表的场景，确保分区剪枝后的查询代价估算准确 多占存储，信息更准 多列统计信息 根据多个列组合收集统计信息 用于多列同时过滤场景，确保对多列组合的查询代价估算准确 手动识别，临时表方式 表达式统计信息 根据表达式函数对某列收集统计信息 用于批量的表达式过滤的场景，确保查询表达式的查询代价估算准确 手动识别 表达式索引信息 创建的表达式索引会自动收集统计信息 用于点查的表达式过滤的场景，确保查询表达式的查询代价估算准确 手动识别 冻结统计信息 将表级的统计信息冻结，防止发生变化 用于数据特征极稳定场景，禁止采样，防止查询计划跳变 用于数据特征极易变场景，强制采样，确保每次查询都采样 参数：表级属性analyze_mode - 修改统计信息 手动计算后，直接修改统计信息 继续低采样率，但可以手动计算后进行校准。用法： select approx_count_distinct(col_name) from table_name; alter table set (n_distinct=xxx) - 分区信息拷贝 可将旧分区的统计信息拷贝到新分区 用于数据特征变化不大的分区表，减少统计信息收集的开销 - 统计信息推理 基于旧的统计信息自动推算更准确的统计信息 通过GUC参数enable_extrapolation_stats设置。 - 统计信息备份恢复 通过explain (stat on) 将统计信息备份成SQL 用于场景复现或统计信息还原 导出SQL的形式

统计信息查看 查看动态采样的内存统计信息。 查内存中表级统计信息： SELECT * FROM pv_runtime_relstats; 查内存中列级统计信息： SELECT * FROM pv_runtime_attstats; 查看系统表中统计信息。 查系统表中表级统计信息： select relname, relpages, reltuples from pg_class; 查系统表中列级统计信息： SELECT * FROM pg_stats; 查看统计信息最近收集时间。 动态采样把统计信息放内存中，不更新该系统表的时间。 SELECT * FROM pg_object;

场景和策略 列举了常见的数据加工场景和对应的统计信息收集策略。 表2 统计信息收集策略 场景 特点 策略 流式增量加工 数据流式增量变化，无合理ANALYZE时机 开启动态采样，查询按需自动收集统计信息，且全局共享 在线批量加工 （ 数据湖 ） 数据加工与查询会并发，要求查询稳定 开启动态采样，或一个事务中完成数据加工和ANALYZE。 begin; truncate table or partition; copy/merge/insert overwrite ANALYZE (light) tablename; end; 分区并行加工 不同分区并发加工数据 开启“动态采样”或“手动light采样”，同表可并发收集 宽表场景 百列以上的宽表 1. 启动动态采样的自动谓词管理。 2. 仅收集前N列的统计信息。 3. 根据查询中常用谓词，可列级设置是否参与采样。 大表场景 表的数据量大，变化难以达到阈值 统计信息易变 调低动态采样触发阈值。 特征敏感场景 数据特征易变，查询计划不稳定 需要强制收集 1. 调低动态采样触发阈值。 2. 在SQL中通过HINT方式强制light动态采样。 3. 清空并冻结统计信息，查询每次都会重新收集且不共享。 高并发场景 同一张表会高并发查询（10并发以上） 同时触发动态采样占用资源多 1. 关闭并发，其它查询不使用最新统计信息。 2. 其它查询等最新统计信息生成，再执行查询（开发中）。 流式性能敏感 流式加工，秒级查询或整体资源高水位 表级或SQL级禁止动态采样，依靠后台轮询采样。 批量性能敏感 批量加工，秒级查询或整体资源高水位 加工时手动收集统计信息。

自动收集统计信息 当配置参数autoanalyze打开时，查询语句走到优化器发现表不存在统计信息或数据变化超过阈值时，会自动触发统计信息收集，以满足优化器的需求。 基于代价的优化器模型（CBO, cost base optimizer）中，统计信息决定了查询计划生成的好坏。因此，统计信息的及时有效很重要。 表级统计信息，存储在pg_class的relpages, reltuples中。 列级统计信息，存储在pg_statistics中，可以通过pg_stats视图查看。包括：NULL值比例，distinct值占比，高频值MCV，直方图histgram等。 收集条件：当数据量发生较大变化，默认是变化10%，认为数据特征已经有了变化，需要重新收集统计信息。 总体策略：开启动态采样保证统计信息及时性，开启轮询采样保证统计信息持久化，查询性能敏感（秒级响应）靠手动采样。

准确性及可靠性 表4 准确性及可靠性 准确性及可靠性 分类 说明 准确性 采样大小 可配置为按表大小自适应。由参数default_statistics_target控制。 采样随机性 analyze_sample_mode参数设置新支持优化蓄水池和range采样随机性更优。 random_function_version参数增强了随机数计算函数的随机性。 全局共享 统计信息可以跨会话和跨节点进行共享。 修改计数广播 后台线程会轮询检全局查修改计数并进行广播。 作业线程也可直接广播修改计数。通过参数tuple_change_sync_threshold设置。 跨CN修改和查询也影响不大，修改计数会异步方式广播同步。 调整CU采样比 CU填充率不高的场景，可调大CU采样比。通过列级参数cstore_cu_sample_ratio设置。 distinct固定 随机采样后distinct值不稳定场景，不调高采样率情况下，可进行distinct值固定。通过列级参数n_distinct设置。 统计信息推算 enable_extrapolation_stats参数可以控制估算失真时，基于旧的统计信息自动推算更准确的统计信息。 可靠性 CN故障 其它CN故障时，不影响动态采样，统计信息不同步，不影响当前CN查询的统计信息质量。 CN恢复 其它CN恢复后，再次查询时会强制动态采样，并全局同步。 DN故障 非当前逻辑集群的DN故障，不影响本逻辑集群的动态采样。

运维监控 GaussDB(DWS)通过在ANALYZE命令后面追加注释的方式，详细展示了ANALYZE运行模式和各种执行阶段，主要通过以下视图体现： 当前活跃会话视图pgxc_stat_activity的query字段。 当前线程等待视图pgxc_thread_wait_status的wait_status字段。 ANALYZE命令追加注释的内容格式为：--Action-RunMode-StatsMode-SyncMode Action取值及含义： {"begin", "finished", "lock FirstCN", "estimate rows", "statistics", "sample rows", "calc stats"}; 分别表示：开始，结束，在向FirstCN申锁，在一阶段估算行数信息，在二阶段真正执行ANALYZE，在采集样本，在计算统计信息。 RunMode取值及含义： {"manual", "backend", "normal runtime", "light runtime", "light runtime inxact", "light estimate rows", "light manual"}; 分别表示：手动模式，后台轮询模式，normal动态采样，light动态采样，事务内的light动态采样，light仅估算函数，手动light模式。 StatsMode取值及含义： {"dynamic", "memory", "smptbl"}; 分别表示：自适应选择内存或临时表放样本，仅使用内存放样本，仅使用临时表放样本。 SyncMode取值及含义： {"sync", "nosync"}; 分别表示：向所有CN同步统计信息，不同步统计信息。 示例： SELECT coorname,datid,datname,pid,usename,application_name,query_id,query FROM pgxc_stat_activity WHERE query like '%analyze%' and query not like '%application_name%'; coorname | datid | datname | pid | usename | application_name | query_id | query --------------+-------+----------+-----------------+-----------+------------------+-------------------+----------------------------------------- coordinator1 | 15676 | postgres | 139919333779200 | test | gsql | 73183493944770822 | analyze t_1; coordinator2 | 15676 | postgres | 140217336461056 | test | coordinator1 | 73183493944770822 | analyze public.t_1;--push stats-manual-memory-sync coordinator3 | 15676 | postgres | 139944245847808 | test | coordinator1 | 73183493944770822 | analyze public.t_1;--push stats-manual-memory-sync (3 rows)

操作步骤 收集SQL中涉及到的所有表的统计信息。在数据库中，统计信息是规划器生成计划的源数据。没有收集统计信息或者统计信息陈旧会造成执行计划严重劣化，从而导致性能问题。从经验数据来看，10%左右性能问题是因为没有收集统计信息。具体请参见更新统计信息。 审视和修改表定义。 通常情况下，有些SQL语句可以通过查询重写转换成等价的，或特定场景下等价的语句。重写后的语句比原语句更简单，且可以简化某些执行步骤达到提升性能的目的。查询重写方法在各个数据库中基本是通用的。SQL语句改写规则介绍了几种常用的通过改写SQL进行调优的方法。 通过查看执行计划来查找原因。如果SQL长时间运行未结束，通过EXPLAIN命令查看执行计划，进行初步定位。如果SQL可以运行出来，则推荐使用EXPLAIN ANALYZE或EXPLAIN PERFORMANCE查看执行计划及实际运行情况，以便更精准地定位问题原因。有关执行计划的详细介绍请参见SQL执行计划。 针对EXPLAIN或EXPLAIN PERFORMANCE信息，定位SQL慢的具体原因以及改进措施，具体参见SQL调优进阶。 用户可以通过指定join顺序，join、stream、scan方法，指定结果行数，指定重分布过程中的倾斜信息等多个手段来进行执行计划的调优，以提升查询的性能。详细请参见使用Plan Hint进行调优。 为了保证数据库性能的持续优质，建议例行维护表和例行重建索引。 （可选）GaussDB(DWS)支持在资源富足的情况下，通过算子并行来提升性能。详细请参见SMP并行执行。

EXPLAIN PERFORMANCE详解 在SQL调优过程中经常需要执行EXPLAIN ANALYZE或EXPLAIN PERFORMANCE查看SQL语句实际执行信息，通过对比实际执行与优化器的估算之间的差别来为优化提供依据。EXPLAIN PERFORMANCE相对于EXPLAIN ANALYZE增加了每个DN上的执行信息。 表定义如下： 1 2 CREATE TABLE tt01(c1 int, c2 int) DISTRIBUTE BY hash(c1); CREATE TABLE tt02(c1 int, c2 int) DISTRIBUTE BY hash(c2); 以如下SQL查询语句为例： 1 SELECT * FROM tt01,tt02 WHERE tt01.c1=tt02.c2; 执行EXPLAIN PERFORMANCE输出的显示执行信息分为以下8个部分： 执行计划 以表格的形式将计划显示出来，包含有11个字段，分别是：id、operation、A-time、A-rows、E-rows、E-distinct、Peak Memory、E-memory、A-width、E-width和E-costs。字段含义如下表1。 表1 执行字段说明 字段 描述 id 执行算子节点编号。 operation 具体的执行节点算子名称。 Vector前缀的算子是指向量化执行引擎算子，一般出现含有列存表的Query中。 Streaming是一个特殊的算子，它实现了分布式架构的核心数据shuffle功能，Streaming共有三种形态，分别对应了分布式结构下不同的数据shuffle功能： Streaming (type: GATHER)：作用是coordinator从DN收集数据。 Streaming(type: REDISTRIBUTE)：作用是DN根据选定的列把数据重分布到所有的DN。 Streaming(type: BROADCAST)：作用是把当前DN的数据广播给其他所有的DN。 A-time 各DN相应算子执行时间，一般DN上执行的算子的A-time是由[]括起来的两个值，分别表示此算子在所有DN上完成的最短时间和最长时间，包括下层算子执行时间。 注意：在整个计划中，除了叶子节点的执行时间是算子本身的执行时间，其余算子的执行时间均包含子节点的执行时间。 A-rows 表示相应算子输出的全局总行数。 E-rows 每个算子估算的输出行数。 E-distinct 表示hashjoin算子的distinct估计值。 Peak Memory 此算子在每个DN上执行时使用的内存峰值，[]中左侧为最小值，右侧为最大值。 E-memory DN上每个算子估算的内存使用量，只有DN上执行的算子会显示。某些场景会在估算的内存使用量后使用括号显示该算子在内存资源充足下可以自动扩展的内存上限。 A-width 表示当前算子每行元组的实际宽度，仅对于重内存使用算子会显示，包括：(Vec)HashJoin、(Vec)HashAgg、(Vec) HashSetOp、(Vec)Sort、(Vec)Materialize算子等，其中(Vec)HashJoin计算的宽度是其右子树算子的宽度，会显示在其右子树上。 E-width 每个算子输出元组的估算宽度。 E-costs 每个算子估算的执行代价。 E-costs是优化器根据成本参数定义的单位来衡量的，习惯上以磁盘页面抓取为1个单位， 其它开销参数将参照它来设置。 每个节点的开销（E-costs值）包括它的所有子节点的开销。 开销只反映了优化器关心的东西，并没有把结果行传递给客户端的时间考虑进去。虽然这个时间可能在实际的总时间里占据相当重要的分量，但是被优化器忽略了，因为它无法通过修改规划来改变。 SQL Diagnostic Information SQL自诊断信息。优化和执行过程中识别到的性能优化点，当对DML语句进行带VERBOSE属性的EXPLAIN（EXPLAIN PERFORMANCE内置自带VERBOSE属性）时，SQL自诊断信息也会输出，以辅助性能问题定位。 Predicate Information (identified by plan id) 谓词过滤这部分主要显示的是对应执行算子节点的过滤条件，即在整个计划执行过程中不会变的信息，主要是一些join条件和一些filter信息。 8.3.0及以上集群版本支持显示与字典计划相关的CU Predicate Filter和Pushdown Predicate Filter(will be pruned)信息。 Memory Information (identified by plan id) 内存使用信息这部分显示的是整个计划中会将内存的使用情况打印出来的算子的内存使用信息，主要是Hash、Sort算子，包括算子峰值内存（peak memory），优化器预估的内存（estimate 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] ）。其中sort算子不会显示具体的下盘文件数，仅在显示排序方法时显示Disk。 Targetlist Information (identified by plan id) 这一部分显示的是每一个算子对应的输出目标列信息。 8.3.0及以上集群版本支持显示与字典相关的Dict Optimized和Dict Decoded，分别表示字典列和字典编码。 DataNode Information (identified by plan id) 这部分将各个算子的执行时间（若包含过滤及投影也会显示对应的执行时间）、CPU、buffer的使用情况全部打印出来。 算子执行信息 每个算子的执行信息都包含三个部分： dn_6001_6002/dn_6003_6004表示具体执行的节点信息，括号中的信息是实际的执行信息。 actual time表示实际的执行时间，第一个数字表示执行时进入当前算子到输出第一条数据所花费的时间，第二个数字表示输出所有数据的总执行时间。 rows表示当前算子输出数据行数。 loops表示当前算子的执行次数。需要注意，对于分区表来说，每一个分区表的扫描就是一次完整的扫描操作，当切换到下一个分区的时候，又是一次新的扫描操作。 CPU信息 每个算子执行的过程都有CPU信息，其中cyc代表的是CPU的周期数，ex cyc表示的是当前算子的周期数，不包含其子节点；inc cyc是包含子节点的周期数；ex row是当前算子输出的数据行数；ex c/r则是ex cyc/ex row得到的每条数据所用的平均周期数。 Buffer信息 buffers显示缓冲区信息，包括共享块和临时块的读和写。 共享块包含表和索引，临时块在排序和物化中使用的磁盘块。上层节点显示出来的块数据包含了其所有子节点使用的块数。 磁盘缓存信息（仅9.1.0.100及以上版本且colversion=3.0的存算分离V3表或外表支持） Disk Cache：表示磁盘缓存的命中信息和数据读取信息。（存算分离V3表或外表支持） miss代表磁盘缓存未命中的次数，hit表示磁盘缓存命中的次数，errorCode见表1，disk_cache_error_code，error表示产生errorCode的次数。scanBytes表示scan查询的数据量，remoteReadBytes表示在OBS上读取的数据量，loadTime表示从磁盘缓存加载数据的时间。为了提升OBS的效率会对相邻的请求块合并，或者因为请求写磁盘缓存的最小粒度是block(默认1M)，可能会使得scanBytes会小于remoteReadBytes。 Column 3.0：存算分离V3表的预读参数与预读过程信息。（仅存算分离V3表支持，开启预读相关参数后显示） preloadStep表示预读的步长，preloadSubmitTime表示预读流程中提交IO请求的时间，preloadWaitTime表示预读流程中等待IO请求的时间，preloadWaitCount表示预读流程中等待IO请求的次数。 OBS I/O ：表示OBS IO请求的详细信息。（存算分离V3表或外表支持） count表示OBS IO请求的总数量，averageRTT表示OBS IO请求的平均RTT(Round Trip Time，IO请求往返时间)，单位为μs，averageLatency表示OBS IO请求的平均延迟，单位为μs，latencyGt1s表示OBS IO请求延迟超过1s的数量，latencyGt10s表示OBS IO请求延迟超过10s的数量，retryCount表示OBS IO请求重试的总次数，rateLimitCount表示OBS IO请求被流控的总次数。 User Define Profiling 自定义信息，这一部分显示的是CN和DN、DN和DN建连的时间，以及存储层的一些执行信息。 Query Summary 这一部分主要打印总的执行时间和网络流量，包括了各个DN上初始化和结束阶段的最大最小执行时间、CN上的初始化、执行、结束阶段的时间，以及当前语句执行时系统可用内存、语句估算内存等信息。 DataNode executor start time：DN执行器开始时间，[min_node_name, max_node_name] : [min_time, max_time] DataNode executor run time：DN执行器运行时间，[min_node_name, max_node_name] : [min_time, max_time] DataNode executor end time：DN执行器结束时间，[min_node_name, max_node_name] : [min_time, max_time] Remote query poll time：接收结果时用于poll等待的时间 System available mem：系统可用内存 Query Max mem：查询最大内存 Enqueue time：入队时间 Coordinator executor start time：CN执行器开始时间 Coordinator executor run time：CN执行器运行时间 Coordinator executor end time：CN执行器结束时间 Parser runtime：解析器运行时间 Planner runtime：优化器执行时间 网络流量，stream算子发送的数据量 Query Id：查询ID Unique SQL ID：约束SQL ID Total runtime：总执行时间 A-rows和E-rows的差异体现了优化器估算和实际执行的偏差度。一般情况下两者偏差越大，则可以认为优化器生成的计划的越不可信，人工干预调优的必要性越大。 A-time中的两个值偏差越大，表明此算子的计算偏斜(在不同DN上执行时间差异)越大，人工干预调优的必要性越大。一般来说，两个相邻的算子，上层算子的执行时间包含下层算子的执行时间，但如果上层算子为stream算子，由于各线程不存在驱动关系，上层算子执行时间可能小于下层算子的执行时间，即不存在包含关系。 Max Query Peak Memory经常用来估算SQL语句耗费内存，也被用来作为SQL语句调优时运行态内存参数设置的重要依据。一般会以EXPLAIN ANALYZE或EXPLAIN PERFORMANCE的输出作为进一步调优的输入。

执行计划显示信息 除了设置不同的执行计划显示格式外，还可以通过不同的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查看执行计划及其实际的运行信息，以便更精准地定位问题原因。 执行计划中的常见关键字说明： 表访问方式 Seq Scan/CStore Scan 全表顺序扫描。最基本的扫描算子，用于行/列存表的顺序扫描。 Index Scan/CStore 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 归并连接或融合连接，是先将关联表的关联列各自做排序，然后从各自的排序表中抽取数据，到另一个排序表中做匹配。 因为Merge join需要做更多的排序，所以消耗的资源更多，因此通常情况下执行性能差于Hash Join。 如果源数据已经被排序过，在执行融合连接时，并不需要再排序，此时Merge Join的性能优于Hash Join。 运算符 sort 对结果集进行排序。 filter EXPLAIN输出显示WHERE子句当作一个"filter"条件附属于顺序扫描计划节点。这意味着规划节点为它扫描的每一行检查该条件，并且只输出符合条件的行。预计的输出行数降低了，因为有WHERE子句。不过，扫描仍将必须访问所有 10000 行，因此开销没有降低；实际上它还增加了一些（确切的说，通过10000 * cpu_operator_cost）以反映检查WHERE条件的额外CPU时间。 LIMIT LIMIT限定了执行结果的输出记录数。如果增加了LIMIT，那么不是所有的行都会被检索到。