华为云用户手册

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

操作步骤 收集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用法，显示不同详细程度的执行计划信息。常见有如下几种，关于更多用法请参见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/ CS tore 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，那么不是所有的行都会被检索到。

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信息。 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) 这一部分显示的是每一个算子对应的输出目标列信息。 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显示缓冲区信息，包括共享块和临时块的读和写。 共享块包含表和索引，临时块在排序和物化中使用的磁盘块。上层节点显示出来的块数据包含了其所有子节点使用的块数。 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的输出作为进一步调优的输入。

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

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

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

LLVM适用场景与限制 适用场景 支持LLVM的表达式。查询语句中存在以下的表达式支持LLVM优化： Case…when… 表达式 In表达式 Bool表达式 (And/Or/Not) BooleanTest表达式 (IS_NOT_KNOWN/IS_UNKNOWN/IS_TRUE/IS_NOT_TRUE/IS_FALSE/IS_NOT_FALSE) NullTest表达式 (IS_NOT_NULL/IS_NULL) Operator表达式 Function表达式 (lpad, substring, btrim, rtrim, length) Nullif表达式 表达式计算支持的数据类型包括bool，tinyint，smallint，int，bigint，float4，float8，numeric，date，time，timetz，timestamp，timestamptz，interval，bpchar，varchar，text，oid。 仅当表达式出现在以下场景时才会考虑是否使用LLVM动态编译优化： 向量化执行引擎中Scan节点的filter； Hash Join节点中的complicate hash condition、hash join filter、hash join target； Nested Loop节点中的filter、join filter； Merge Join节点的merge join filter、merge join target； Group节点中的filter表达式。

LLVM使用建议 目前LLVM在数据库内核侧已默认打开，用户可结合上述的分析进行配置，总体建议如下： 设置合理的work_mem，在允许的条件下尽可能设置较大的work_mem，如果出现大量下盘，则建议关闭LLVM动态编译优化（通过设置enable_codegen=off实现）。 设置合理的codegen_cost_threshold(默认值为10000)，确保小数据量场景下避免使用LLVM动态编译优化。当codegen_cost_threshold的值设定后，因使用LLVM动态编译优化引入性能劣化，则建议增加codegen_cost_threshold的取值。 对于表达式计算使用LLVM动态编译优化，如果存在大量的调用C-函数的场景，建议关闭LLVM动态编译优化。 In表达式后常量列表长度不能超过10，否则不能执行LLVM编译优化。 在资源许可的情况下，数据量越大，可获得的性能提升效果越好。

其他因素对LLVM性能的影响 LLVM优化效果不仅依赖于数据库内部具体的实现，还与当前所选择的硬件环境等有关。 表达式调用C-函数个数 数据库内部针对表达式计算并未实现全codegen，即在整个表达式计算中部分表达式实现了codegen，部分直接调用原本的C代码。如果整个表达式计算中后者占据了主要部分，使用LLVM动态编译优化，可能会导致性能劣化。通过设置log_min_messages的级别为DEBUG1可以查看到哪些表达式直接调用了C代码实现。 内存资源 LLVM特性的一个重要思想是保障数据的局域特性，即数据应尽可能的存放在寄存器中。同时应减少数据加载，因此在使用LLVM优化时应设置足够大的work_mem，保证对应使用LLVM优化的执行代码整个过程在内存中实现，否则可能引起性能劣化。 优化器代价估算 LLVM特性实现了简易的代价估算模型，即依据当前参与节点运算的表大小决定当前节点是否考虑使用LLVM动态编译优化。如果优化器低估了实际参与运算的行数，则原本可获得收益的未正常获得收益。反之亦然。

资源对SMP性能的影响 SMP架构是一种利用富余资源来换取时间的方案，计划并行之后必定会引起资源消耗的增加，包括CPU、内存、I/O和网络带宽等资源的消耗都会出现明显的增长，而且随着并行度的增大，资源消耗也随之增大。当上述资源成为瓶颈的情况下，SMP无法提升性能，反而可能导致集群整体性能的劣化。SMP支持自适应特性，该特性会根据当前资源和查询特征，动态选取最优的并行度。下面对各种资源对SMP性能的影响情况分别进行说明： CPU资源 在一般客户场景中，系统CPU利用率不高的情况下，利用SMP并行架构能够更充分地利用系统CPU资源，提升系统性能。但当数据库服务器的CPU核数较少，CPU利用率已经比较高的情况下，如果打开SMP并行，不仅性能提升不明显，反而可能因为多线程间的资源竞争而导致性能劣化。 内存资源 查询并行后会导致内存使用量的增长，但每个算子使用内存上限仍受到work_mem等参数的限制。假设work_mem为4GB，并行度为2，那么每个并行线程所分到的内存上限为2GB。在work_mem较小或者系统内存不充裕的情况下，使用SMP并行后，可能出现数据下盘，导致查询性能劣化的问题。 网络带宽资源 为了实现查询并行执行，会新增并行线程间的数据交换算子。对于Local类Stream算子，所需要进行数据交换的线程在同一个DN内，通过内存交换，不会增加网络负担。而非Local类算子，需要通过网络进行数据交换，因此会加重网络负担。当网络资源成为瓶颈的情况下，并行可能会导致一定程度的劣化。 I/O资源 要实现并行扫描必定会增加I/O的资源消耗，因此只有在I/O资源充足的情况下，并行扫描才能够提高扫描性能。

SMP相关参数配置建议 如果要打开SMP自适应功能，要设置query_dop=0，需同步调整以下相关参数值，以获取更佳的dop选择： comm_usable_memory 当系统内存较大时，max_process_memory设置较大，可适当调大该值，建议设置为max_process_memory的5%，默认值为4GB。 comm_max_stream 设置建议值为：comm_max_stream=Min(dop_limit * dop_limit * 20 * 2, max_process_memory(字节数) * 0.025 / 总DN数 / 260)，且该值在comm_max_stream取值范围内。 max_connections 设置建议值为：max_connections=dop_limit * 20 * 6 + 24，且该值在max_connections取值范围内。 公式中的dop_limit为集群中每个DN对应的CPU数，计算公式为：dop_limit = 单机器的CPU逻辑核数 / 单机器的DN数。

其他因素对SMP性能的影响 除了资源因素外，还有一些因素也会对SMP并行性能造成影响。例如分区表中分区数据不均，以及系统并发度等因素。 数据倾斜对SMP性能的影响 当数据中存在严重数据倾斜时，并行效果较差。例如某表join列上某个值的数据量远大于其他值，开启并行后，根据join列的值对该表数据做hash重分布，使得某个并行线程的数据量远多于其他线程，造成长尾问题，导致并行后效果差。 系统并发度对SMP性能的影响 SMP特性会增加资源的使用，而在高并发场景下资源剩余较少。所以，如果在高并发场景下，开启SMP并行，会导致各查询之间严重的资源竞争问题。一旦出现了资源竞争的现象，无论是CPU、I/O、内存或者网络资源，都会导致整体性能的下降。因此在高并发场景下，开启SMP经常不能达到性能提升的效果，甚至可能引起性能劣化。

SMP适用场景与限制 SMP适用场景： 支持并行的算子 计划中存在以下算子支持并行： Scan：支持行存普通表和行存分区表顺序扫描、列存普通表和列存分区表顺序扫描、HDFS内外表顺序扫描；支持GDS数据导入的外表扫描并行。以上均不支持复制表。 Join：HashJoin、NestLoop Agg：HashAgg、SortAgg、PlainAgg、WindowAgg(只支持partition by，不支持order by) Stream：Redistribute、Broadcast 其他：Result、Subqueryscan、Unique、Material、Setop、Append、VectoRow、RowToVec SMP特有算子 为了实现并行，新增了并行线程间的数据交换Stream算子供SMP特性使用。以下新增的算子可以看做Stream算子的子类： Local Gather：实现DN内部并行线程的数据汇总 Local Redistribute：在DN内部各线程之间，按照分布键进行数据重分布 Local Broadcast：将数据广播到DN内部的每个线程 Local RoundRobin：在DN内部各线程之间实现数据轮询分发 Split Redistribute：在集群跨DN的并行线程之间实现数据重分布 Split Broadcast：将数据广播到集群所有DN的并行线程 上述新增算子可以分为Local与非Local两类，Local类算子实现了DN内部并行线程间的数据交换，而非Local类算子实现了跨DN的并行线程间的数据交换。 示例说明 以TPCH Q1的并行计划为例： 在这个计划中，实现了Hdfs Scan以及HashAgg算子的并行，并且新增了Local Gather和Split Redistribute数据交换算子。 其中6号算子为Split Redistribute算子，上面标有的“dop: 4/4”表明Split Redistribute的发送端和接收端线程的并行度均为4。4号算子为Local Gather，上面标有“dop: 1/4”，该算子的发送端线程并行度为4，而接收端线程并行度为1，即下层的5号Hash Aggregate算子按照4并行度执行，而上层的1~3号算子按照串行执行，4号算子实现了DN内并行线程的数据汇总。 通过计划Stream算子上标明的dop信息即可看出各个算子的并行情况。 非适用场景：

操作步骤 查看阻塞的查询语句及阻塞查询的表、模式信息。 1 2 3 4 5 6 7 8 9 10 11 SELECT w.query as waiting_query, w.pid as w_pid, w.usename as w_user, l.query as locking_query, l.pid as l_pid, l.usename as l_user, t.schemaname || '.' || t.relname as tablename from pg_stat_activity w join pg_locks l1 on w.pid = l1.pid and not l1.granted join pg_locks l2 on l1.relation = l2.relation and l2.granted join pg_stat_activity l on l2.pid = l.pid join pg_stat_user_tables t on l1.relation = t.relid where w.waiting; 该查询返回线程ID、用户信息、查询状态，以及导致阻塞的表、模式信息。 使用如下命令结束相应的会话。其中，139834762094352为线程ID。 1 SELECT PG_TERMINATE_BACKEND(139834762094352); 显示类似如下信息，表示结束会话成功。 PG_TERMINATE_BACKEND ---------------------- t (1 row) 显示类似如下信息，表示用户正在尝试结束当前会话，此时仅会重连会话，而不是结束会话。 FATAL: terminating connection due to administrator command FATAL: terminating connection due to administrator command The connection to the server was lost. Attempting reset: Succeeded. gsql客户端使用PG_TERMINATE_BACKEND函数终止本会话后台线程时，客户端不会退出而是自动重连。

集群性能分析 GaussDB(DWS)不同集群规格的CPU核数、内存大小和节点存储容量不同，处理业务能力和性能也就不同，用户在创建集群前需要结合实际业务量和具体使用场景来选择集群规格。 在使用集群过程中，当用户的业务量过大，则需要更多的资源（CPU、内存、网络带宽等）来支撑逐渐增长的业务量，如果用户当前使用的集群资源不足，会降低数据库运行速度并影响数据库性能。 GaussDB(DWS)监控信息功能提供了丰富的监控指标，您可以通过集群的各项监控指标（CPU使用率、内存使用率、磁盘使用率、磁盘I/O、网络I/O等），掌握集群的性能和运行状况。当您发现监控指标存在异常时，可以通过查看集群监控指标排查出现异常的原因。具体查看方法可参考“在监控面板(DMS)查看GaussDB(DWS)集群监控”章节。 如果需要更多的计算资源或存储资源以满足业务需要时，可以在管理控制台对已有集群，进行规格变更或扩容操作。具体内容可参考GaussDB(DWS)集群规格变更和集群扩容。 父主题： 性能诊断

注意事项 数据库调优是一个复杂和细致的过程，需熟悉数据库系统的内部工作原理和相关技术。它需要综合考虑硬件、软件、查询、配置和数据结构等多个方面的因素，以达到最佳的性能和效率。因此，要求调优人员应对系统软件架构、软硬件配置、数据库配置参数、并发控制、查询处理和数据库应用有广泛而深刻的理解。 性能调优过程有时需要重启集群，可能会中断当前业务。建议在业务低峰期进行需要重启集群的性能调优操作，避免业务异常中断。

调优流程 调优流程如图1所示。 图1 GaussDB(DWS)性能调优流程 调优各阶段说明，如表1所示。 表1 GaussDB(DWS)性能调优流程说明 阶段 描述 性能诊断 获取集群各节点的CPU、内存、I/O和网络资源使用情况，确认这些资源是否已被充分利用，是否存在瓶颈点。 系统调优 进行操作系统级以及数据库系统级的调优，更充分地利用机器的CPU、内存、I/O和网络资源，避免资源冲突，提升整个系统查询的吞吐量。 SQL调优 审视业务所用SQL语句是否存在可优化空间，包括： 通过ANALYZE语句生成表统计信息：ANALYZE语句可收集与数据库中表内容相关的统计信息，统计结果存储在系统表PG_STATISTIC中。执行计划生成器会使用这些统计数据，以确定最有效的执行计划。 分析执行计划：EXPLAIN语句可显示SQL语句的执行计划，EXPLAIN PERFORMANCE语句可显示SQL语句中各算子的执行时间。 查找问题根因并进行调优：通过分析执行计划，找到可能存在的原因，进行针对性的调优，通常为调整数据库级SQL调优参数。 编写更优的SQL：介绍一些复杂查询中的中间临时数据缓存、结果集缓存、结果集合并等场景中的更优SQL语法。

配置集群参数 查询TopSQL资源监控信息之前，需要先配置相关的GUC参数，以便能查询到作业的资源监控历史信息或归档信息。步骤如下： 登录GaussDB(DWS)管理控制台。 在“集群管理”页面，找到所需要的集群，单击集群名称，进入集群详情页面。 单击“参数修改”标签页，可以看到当前集群的参数值。 修改参数resource_track_duration值为合适的值，单击“保存”按钮进行保存。 enable_resource_record开关打开后，会引起存储空间膨胀及轻微性能影响，不用时请关闭。 返回集群管理页面，单击右上角的刷新按钮，等待集群参数配置完成。

操作步骤 通过视图gs_session_cpu_statistics查询实时CPU信息。 1 SELECT * FROM gs_session_cpu_statistics; 通过视图gs_session_memory_statistics查询实时memory信息。 1 SELECT * FROM gs_session_memory_statistics; 通过视图gs_wlm_session_statistics查询当前CN的实时资源。 1 SELECT * FROM gs_wlm_session_statistics; 通过视图pgxc_wlm_session_statistics查询所有CN的实时资源。 1 SELECT * FROM pgxc_wlm_session_statistics; 通过视图gs_wlm_operator_statistics查询当前CN作业算子执行实时资源信息。 1 SELECT * FROM gs_wlm_operator_statistics; 通过视图pgxc_wlm_operator_statistics查询所有CN作业算子执行实时资源信息。 1 SELECT * FROM pgxc_wlm_operator_statistics; 通过视图pg_session_wlmstat查询当前用户执行作业正在运行时的负载管理信息。 1 SELECT * FROM pg_session_wlmstat; 通过视图pgxc_wlm_workload_records（动态负载功能开启，即enable_dynamic_workload为on时该视图有效）查询当前用户在每个CN上作业执行时的状态信息。 1 SELECT * FROM pgxc_wlm_workload_records;

前提条件 GUC参数enable_resource_track为on （默认为on）。 GUC参数resource_track_level为query、perf或operator（默认为query）。 监控作业的类型为： 优化器估算的执行代价大于或等于resource_track_cost取值的作业。 Cgroups功能正常加载，可通过gs_cgroup -P查看控制组信息。 GUC参数enable_track_record_subsql控制是否记录存储过程、匿名块内部语句。 在上述条件中，enable_resource_track为系统级参数，用于设置是否开启资源监控功能。resource_track_level为session级参数，可以对某个session的资源监控级别进行灵活设置。这两个参数的设置方法如下表： 表2 设置资源监控信息统计级别 enable_resource_track resource_track_level query级别信息 算子级别信息 on(default) none 不统计 不统计 query(default) 统计 不统计 perf 统计 不统计 operator 统计 统计 off none/query/operator 不统计 不统计

内存监控 GaussDB(DWS)提供了监控整个集群内存使用状态的视图： 查询pgxc_total_memory_detail视图，必须具有sysadmin权限。 1 SELECT * FROM pgxc_total_memory_detail; 如果查询该视图时出现以下错误，请开启内存管理功能。 1 2 3 SELECT * FROM pgxc_total_memory_detail; ERROR: unsupported view for memory protection feature is disabled. CONTEXT: PL/pgSQL function pgxc_total_memory_detail() line 12 at FOR over EXECUTE statement 用户可通过GaussDB(DWS) 控制台设置enable_memory_limit和max_process_memory参数来开启内存管理功能，方法如下： 登录GaussDB(DWS) 管理控制台。 在左侧导航栏中，单击“集群管理”。 在集群列表中找到所需要的集群，单击集群名称，进入集群“基本信息”页面。 单击“参数修改”页签，修改参数“enable_memory_limit”的值为on，然后单击“保存”。 修改参数“max_process_memory”的值为合适的值，修改建议请参见max_process_memory，然后单击“保存”。 在“修改预览”窗口，确认修改无误后，单击“保存”。修改完成后需要重启集群，参数才会生效。

操作步骤 查询所有用户的资源限额和资源实时使用情况。 1 SELECT * FROM PG_TOTAL_USER_RESOURCE_INFO; 得到的结果视图如下： 1 2 3 4 5 6 7 username | used_memory | total_memory | used_cpu | total_cpu | used_space | total_space | used_temp_space | total_temp_space | used_spill_space | total_spill_space | read_kbytes | write_kbytes | read_counts | write_counts | read_speed | write_speed -----------------------+-------------+--------------+----------+-----------+------------+-------------+-----------------+------------------+------------------+-------------------+-------------+--------------+-------------+--------------+------------+------------- perfadm | 0 | 0 | 0 | 0 | 0 | -1 | 0 | -1 | 0 | -1 | 0 | 0 | 0 | 0 | 0 | 0 usern | 0 | 17250 | 0 | 48 | 0 | -1 | 0 | -1 | 0 | -1 | 0 | 0 | 0 | 0 | 0 | 0 userg | 34 | 15525 | 23.53 | 48 | 0 | -1 | 0 | -1 | 814955731 | -1 | 6111952 | 1145864 | 763994 | 143233 | 42678 | 8001 userg1 | 34 | 13972 | 23.53 | 48 | 0 | -1 | 0 | -1 | 814972419 | -1 | 6111952 | 1145864 | 763994 | 143233 | 42710 | 8007 (4 rows) 其中，IO资源监控字段(read_kbytes、write_kbytes、read_counts、write_counts、read_speed和write_speed)需要在GUC参数enable_user_metric_persistent开启时才有监控数据。 所查各字段说明详见PG_TOTAL_USER_RESOURCE_INFO 。 查询具体某个用户的资源限额和资源实时使用情况。 1 SELECT * FROM GS_WLM_USER_RESOURCE_INFO('username'); 查询结果如下： 1 2 3 4 userid | used_memory | total_memory | used_cpu | total_cpu | used_space | total_space | used_temp_space | total_temp_space | used_spill_space | total_spill_space | read_kbytes | write_kbytes | read_counts | write_counts | read_speed | write_speed --------+-------------+--------------+----------+-----------+------------+-------------+-----------------+------------------+------------------+-------------------+-------------+--------------+-------------+--------------+------------+------------- 16407 | 18 | 1655 | 6 | 19 | 13787176 | -1 | 0 | -1 | 0 | -1 | 0 | 0 | 0 | 0 | 0 | 0 (1 row) 查询所有用户的资源限额和资源历史使用情况。 1 SELECT * FROM GS_WLM_USER_RESOURCE_HISTORY; 查询结果如下： 1 2 3 4 5 username | timestamp | used_memory | total_memory | used_cpu | total_cpu | used_space | total_space | used_temp_space | total_temp_space | used_spill_space | total_spill_space | read_kbytes | write_kbytes | read_counts | write_counts | read_speed | write_speed -----------------------+-------------------------------+-------------+--------------+----------+-----------+------------+-------------+-----------------+------------------+------------------+-------------------+-------------+--------------+-------------+--------------+-------------+------------- usern | 2020-01-08 22:56:06.456855+08 | 0 | 17250 | 0 | 48 | 0 | -1 | 0 | -1 | 88349078 | -1 | 45680 | 34 | 5710 | 8 | 320 | 0 userg | 2020-01-08 22:56:06.458659+08 | 0 | 15525 | 33.48 | 48 | 0 | -1 | 0 | -1 | 110169581 | -1 | 17648 | 23 | 2206 | 5 | 123 | 0 userg1 | 2020-01-08 22:56:06.460252+08 | 0 | 13972 | 33.48 | 48 | 0 | -1 | 0 | -1 | 136106277 | -1 | 17648 | 23 | 2206 | 5 | 123 | 0 对于系统表GS_WLM_USER_RESOURCE_HISTORY，仅当GUC参数enable_user_metric_persistent开启时，才会定期将视图PG_TOTAL_USER_RESOURCE_INFO中的数据保存到历史表中。 所查各字段说明详见GS_WLM_USER_RESOURCE_HISTORY。

注意事项 用户监控可以同时监控快慢车道（快车道管控简单作业，慢车道管控复杂作业）所有作业的CPU、IO和内存使用情况，不再受限于仅监控慢车道作业。 当前快车道作业内存和CPU不受控，在快车道运行作业占用资源较多情况下，可能出现已用资源大于资源限制的情况。 DN监控视图中，IO、内存和CPU显示的是本DN上资源池资源使用和资源限制信息。 CN监控视图中，IO、内存和CPU显示的是集群内所有DN资源池资源使用和资源限制的累积和。 DN每隔5s更新一次监控信息，CN每隔5s从DN收集一次用户监控信息，因为各实例单独更新/收集用户监控信息，因此各实例监控信息更新时间可能不一致。 辅助线程中每隔30s自动调用持久化函数，持久化用户监控数据，正常情况下不需要用户单独调用持久化函数持久化用户监控数据。 当用户数量较多，集群规模较大时，查询此类实时视图，因CN/DN间实时通信开销，会有一定的网络延时。 初始管理用户不进行资源监控。

空间索引 GaussDB(DWS)数据库的PostGIS Extension支持GIST (Generalized Search Tree) 空间索引（分区表除外）。相比于B-tree索引，GIST索引适应于任意类型的非常规数据结构，可有效提高几何和地理数据信息的检索效率。 使用如下命令创建GIST索引： 1 CREATE INDEX indexname ON tablename USING GIST ( geometryfield );

PostGIS概述 PostGIS Extension依赖的第三方软件需要用户进行单独安装，用户如需使用PostGIS功能，请提交工单或联系技术支持人员提交申请。 如果用户在使用中出现“ERROR：EXTENSION is not yet supported.”这种报错，则表示没有安装PostGIS软件包，请联系技术支持进行获取。 GaussDB(DWS)提供PostGIS Extension（支持版本为PostGIS-2.4.2）。PostGIS Extension是PostgreSQL的空间数据库扩展，提供如下空间信息服务功能：空间对象、空间索引、空间操作函数和空间操作符。PostGIS Extension完全遵循OpenGIS规范。 GaussDB(DWS)中PostGIS Extension依赖第三方开源软件如下。 Geos 3.6.2 Proj 4.9.2 Json 0.12.1 Libxml2 2.7.1 Gdal 1.11.0 父主题： 使用PostGIS Extension

常见问题处理 Server common name "xxxx" does not match host name "xxxxx" 此问题的原因是使用了SSL加密的“verify-full”选项，这时驱动程序会验证证书中的主机名与实际部署数据库的主机名是否一致。碰到此问题可以使用“verify-ca”选项，不再校验主机名；或者重新生成一套与数据库所在主机名相同的CA证书。 connect to server failed: no such file or directory 此问题可能的原因： 配置了错误的/不可达的数据库地址，或者端口 请检查数据源配置中的Servername及Port配置项。 服务器监听不正确 如果确认Servername及Port配置正确，请根据“操作步骤”中数据库服务器的相关配置，确保数据库监听了合适的网卡及端口。 防火墙及网闸设备 请确认防火墙设置，将数据库的通信端口添加到可信端口中。 如果有网闸设备，请确认相关的设置。 在指定的DSN中，驱动程序和应用程序之间的体系结构不匹配 此问题可能的原因：在64位程序中使用了32位驱动，或者相反。 C:\Windows\SysWOW64\odbcad32.exe：这是32位ODBC驱动管理器。 C:\Windows\System32\odbcad32.exe：这是64位ODBC驱动管理器。 The password-stored method is not supported. 此问题可能原因： 数据源中未配置sslmode配置项，请调整此项至allow或以上级别，允许SSL连接，此选项的更多说明，请见表1。 authentication method 10 not supported. 使用开源客户端碰到此问题，可能原因： 数据库中存储的口令校验只存储了SHA256格式哈希，而开源客户端只识别MD5校验，双方校验方法不匹配报错。 数据库并不存储用户口令，只存储用户口令的哈希码。 早期版本（V100R002C80SPC300之前的版本）的数据库只存储了SHA256格式的哈希，并未存储MD5的哈希，所以无法使用MD5做用户口令校验。 新版本（V100R002C80SPC300及之后版本）的数据库当用户更新用户口令或者新建用户时，会同时存储两种格式的哈希码，这时将兼容开源的认证协议。 但是当老版本升级到新版本时，由于哈希的不可逆性，所以数据库无法还原用户口令，进而生成新格式的哈希，所以仍然只保留了SHA256格式的哈希，导致仍然无法使用MD5做口令认证。 要解决该问题，参见以下操作： 新建一个数据库用户用于连接，或者重置准备使用的数据库用户的密码。 如果您使用的是管理员账号，参见重置密码。 如果是普通用户，可以先通过其他客户端工具（例如Data Studio）连接数据库后，使用ALTER USER语句来修改密码。 再尝试连接数据库。 unsupported frontend protocol 3.51: server supports 1.0 to 3.0 目标数据库版本过低，或者目标数据库为开源数据库。请使用对应版本的数据库驱动连接目标数据库。

常见问题处理 [UnixODBC][Driver Manager]Can't open lib 'xxx/xxx/psqlodbcw.so' : file not found. 此问题的可能原因： odbcinst.ini文件中配置的路径不正确。 确认的方法：执行ls命令确认错误信息中的路径，以确保该psqlodbcw.so文件存在，同时具有执行权限。 psqlodbcw.so的依赖库不存在，或者不在系统环境变量中。 确认的办法：执行ldd命令确认错误信息中的路径，如果是缺少libodbc.so.1等UnixODBC的库，那么按照“操作步骤”中的方法重新配置UnixODBC，并确保它的安装路径下的lib目录添加到了LD_LIBRARY_PATH中；如果是缺少其他库，请将ODBC驱动包中的lib目录添加到LD_LIBRARY_PATH中。 [UnixODBC]connect to server failed: no such file or directory 此问题可能的原因： 配置了错误的/不可达的数据库地址，或者端口。 请检查数据源配置中的Servername及Port配置项。 服务器监听不正确。 如果确认Servername及Port配置正确，请根据“操作步骤”中数据库服务器的相关配置，确保数据库监听了合适的网卡及端口。 防火墙及网闸设备。 请确认防火墙设置，将数据库的通信端口添加到可信端口中。 如果有网闸设备，请确认相关的设置。 [unixODBC]The password-stored method is not supported. 此问题可能原因： 数据源中未配置sslmode配置项。 解决办法： 请配置该选项至allow或以上选项。此配置的更多信息，见表3。 Server common name "xxxx" does not match host name "xxxxx" 此问题的原因： 使用了SSL加密的“verify-full”选项，驱动程序会验证证书中的主机名与实际部署数据库的主机名是否一致。 解决办法： 碰到此问题可以使用“verify-ca”选项，不再校验主机名；或者重新生成一套与数据库所在主机名相同的CA证书。 Driver's SQLAllocHandle on SQL_HANDLE_DBC failed 此问题的可能原因： 可执行文件（比如UnixODBC的isql，以下都以isql为例）与数据库驱动（psqlodbcw.so）依赖于不同的odbc的库版本：libodbc.so.1或者libodbc.so.2。此问题可以通过如下方式确认： ldd `which isql` | grep odbc ldd psqlodbcw.so | grep odbc 这时，如果输出的libodbc.so最后的后缀数字不同或者指向不同的磁盘物理文件，那么基本就可以断定是此问题。isql与psqlodbcw.so都会要求加载libodbc.so，这时如果它们加载的是不同的物理文件，便会导致两套完全同名的函数列表，同时出现在同一个可见域里（UnixODBC的libodbc.so.*的函数导出列表完全一致），产生冲突，无法加载数据库驱动。 解决办法： 确定一个要使用的UnixODBC，然后卸载另外一个（比如卸载库版本号为.so.2的UnixODBC），然后将剩下的.so.1的库，新建一个同名但是后缀为.so.2的软链接，便可解决此问题。 FATAL: Forbid remote connection with trust method! 由于安全原因，数据库CN禁止集群内部其他节点无认证接入。 如果要在集群内部访问CN，请将ODBC程序部署在CN所在机器，服务器地址使用"127.0.0.1"。建议业务系统单独部署在集群外部，否则可能会影响数据库运行性能。 [unixODBC][Driver Manager]Invalid attribute value 在使用SQL on other GaussDB功能时碰到此问题，有可能是unixODBC的版本并非推荐版本，建议通过“odbcinst --version”命令排查环境中的unixODBC版本。 authentication method 10 not supported. 使用开源客户端碰到此问题，可能原因： 数据库中存储的口令校验只存储了SHA256格式哈希，而开源客户端只识别MD5校验，双方校验方法不匹配报错。 数据库并不存储用户口令，只存储用户口令的哈希码。 早期版本（V100R002C80SPC300之前的版本）的数据库只存储了SHA256格式的哈希，并未存储MD5的哈希，所以无法使用MD5做用户口令校验。 新版本（V100R002C80SPC300及之后版本）的数据库当用户更新用户口令或者新建用户时，会同时存储两种格式的哈希码，这时将兼容开源的认证协议。 但是当老版本升级到新版本时，由于哈希的不可逆性，所以数据库无法还原用户口令，进而生成新格式的哈希，所以仍然只保留了SHA256格式的哈希，导致仍然无法使用MD5做口令认证。 要解决该问题，可以更新用户口令；或者新建一个用户，赋予同等权限，使用新用户连接数据库。 unsupported frontend protocol 3.51: server supports 1.0 to 3.0 目标数据库版本过低，或者目标数据库为开源数据库。请使用对应版本的数据库驱动连接目标数据库。

javax.naming.Context javax.naming.Context是连接配置的上下文接口。 表12 对javax.naming.Context的支持情况 方法名 返回值类型 支持JDBC 4 bind(Name name, Object obj) void Yes bind(String name, Object obj) void Yes lookup(Name name) Object Yes lookup(String name) Object Yes rebind(Name name, Object obj) void Yes rebind(String name, Object obj) void Yes rename(Name oldName, Name newName) void Yes rename(String oldName, String newName) void Yes unbind(Name name) void Yes unbind(String name) void Yes

CopyManager CopyManager是GaussDB(DWS) JDBC驱动中提供的一个API接口类，用于批量向GaussDB(DWS)集群中导入数据。 CopyManager的继承关系 CopyManager类位于org.postgresql.copy Package中，继承自java.lang.Object类，该类的声明如下： public class CopyManager extends Object 构造方法 public CopyManager(BaseConnection connection) throws SQLException 常用方法 表14 CopyManager常用方法 返回值 方法 描述 throws CopyIn copyIn(String sql) - SQLException long copyIn(String sql, InputStream from) 使用COPY FROM STDIN从InputStream中快速向数据库中的表加载数据。 SQLException,IOException long copyIn(String sql, InputStream from, int bufferSize) 使用COPY FROM STDIN从InputStream中快速向数据库中的表加载数据。 SQLException,IOException long copyIn(String sql, Reader from) 使用COPY FROM STDIN从Reader中快速向数据库中的表加载数据。 SQLException,IOException long copyIn(String sql, Reader from, int bufferSize) 使用COPY FROM STDIN从Reader中快速向数据库中的表加载数据。 SQLException,IOException CopyOut copyOut(String sql) - SQLException long copyOut(String sql, OutputStream to) 将一个COPY TO STDOUT的结果集从数据库发送到OutputStream类中。 SQLException,IOException long copyOut(String sql, Writer to) 将一个COPY TO STDOUT的结果集从数据库发送到Writer类中。 SQLException,IOException