profile    这是sqoop 路径这是测试sqoop是否安装成功所返回的

性能调优是应用迁移或开发过程中的关键步骤，同时也在整个项目实施过程中占据很大的份量，在很多实施步骤中都需要进行考虑。主要介绍数据库级别的性能调优思路和总体策略，助力GaussDB DWS使用者深谙调优精髓，更好地完成应用实施过程中的各项调优任务。 GaussDB处理的操作类型https://bbs.huaweicloud.com/forum/thread-02104147168146295005-1-1.htmlGaussDB(DWS)性能调优https://bbs.huaweicloud.com/forum/thread-0277147168588691003-1-1.htmlGaussDB(DWS)性能调优系列实战篇https://bbs.huaweicloud.com/forum/thread-02109147168854691008-1-1.htmlGaussDB(DWS)性能调优系列实战篇之十八般武艺https://bbs.huaweicloud.com/forum/thread-0274147169085248005-1-1.htmlGaussDB(DWS)执行算子介绍https://bbs.huaweicloud.com/forum/thread-02109147169299951009-1-1.htmlGaussDB(DWS)之EXPLAIN用法介绍https://bbs.huaweicloud.com/forum/thread-02127147169513665006-1-1.htmlGaussDB(DWS)性能调优系列之query执行流程https://bbs.huaweicloud.com/forum/thread-02104147173806654006-1-1.htmlGaussDB(DWS)性能调优系列之CBO模型https://bbs.huaweicloud.com/forum/thread-0274147174087244007-1-1.htmlGaussDB(DWS)性能调优系列之如何生成统计信息https://bbs.huaweicloud.com/forum/thread-0207147174219702008-1-1.htmlGaussDB(DWS)性能调优系列之什么时候收集统计信息https://bbs.huaweicloud.com/forum/thread-0277147174333643005-1-1.htmlGaussDB(DWS)性能调优系列基础篇之衍化至繁之分布式计划详解https://bbs.huaweicloud.com/forum/thread-02104147175009699007-1-1.htmlGaussDB(DWS)性能调优系列实战篇之SQL识别https://bbs.huaweicloud.com/forum/thread-02109147175614711011-1-1.htmlGaussDB(DWS)性能调优系列实战篇之表定义https://bbs.huaweicloud.com/forum/thread-0296147175801701007-1-1.htmlGaussDB(DWS)之数据分布方式设计https://bbs.huaweicloud.com/forum/thread-0296147176521895008-1-1.htmlGaussDB(DWS)之SQL改写https://bbs.huaweicloud.com/forum/thread-0277147176883052006-1-1.html

数据库的应用中，充斥着坏味道的SQL，非常影响查询的性能。坏味道SQL，即由于开发者写的随意，导致执行性能较差，需要通过优化SQL语句进行调优的SQL。在GaussDB(DWS)分布式场景下，相对于单机环境，将出现更多的坏味道SQL语句。本文将系统介绍在GaussDB(DWS)系统中影响性能的坏味道SQL及SQL模式，帮助大家能够从原理层面尽快识别这些坏味道SQL，在调优过程中及时发现问题，进行整改。从大的方面来看，主要包含不支持下推导致的坏味道、不支持重分布导致的坏味道、数据类型转换导致的坏味道、全局性操作导致的坏味道、NestLoop类低效运算导致的坏味道和冗余操作导致的坏味道。本文将介绍每一类坏味道的原因，以及如何进行SQL改写及调优。在GaussDB(DWS)分布式场景下，数据运算应该全部下推到DN上执行，才能获得比较好的性能收益。但对于某些场景，数据必须在CN上执行，导致语句无法全部下推到DN运算，会导致两个主要的瓶颈点：（1）只有基表扫描在DN执行，需要将大量数据传输到CN上，网络开销增大。（2）原先可以在DN上分布式执行的数据，均由CN单个执行，瓶颈加大。通常情况下，我们不支持不下推函数、复合类型、复杂语法及组合（例如：某些场景的with recursive语法，rollup函数+多count(distinct)语法）的下推，所以应该尽量避免在语句中使用以上元素。在客户场景中，经常遇到函数不能下推导致的问题，本篇博文重点以函数下推为例，讲述如何解决类似的问题。如下图计划所示，在语句中包含了不支持下推的函数unship_func()，导致整个计划不能下推，计划中出现“_REMOTE_TABLE_QUERY_”的字样，即会出现上述的瓶颈问题。遇到类似问题，需要根据具体应用场景，为函数设置合理的下推属性，使其可以下推。以上两个属性可以通过系统表pg_proc的provalitile和proshippable字段查询。目前GaussDB以CN/DN行为是否一致作为下推标准，支持大部分immutable和stable函数的下推，以及特定场景少量volatile函数的下推。对于用户自定义函数，由于数据库无法知晓函数的行为，因为不知道函数的属性，因为默认是volatile和unshippable的。包含对应函数的语句将无法下推到DN执行。用户可以根据函数的行为，判断返回结果是否恒定，以及是否可以下推，设置对应的属性。具体的设置方法为：（1）如果函数的返回结果是恒定的，比如数字计算函数，日期计算函数，则可以为其设置immutable属性。（2）如果函数中使用了数据表，且数据表均是复制表的只读操作且不涉及事务操作（所以DN数据均相同，可以下推到一个DN上执行），则可以为其设置shippable属性。其余情况则还是不能下推，如果错误设置，会引发不可预知错误，因此需要慎重设置。转载：https://mp.weixin.qq.com/s/Jy27HVRIIuEXddrifXFlFw

GaussDB(DWS)的MPP架构，天然支持通过散列的方式进行水平分表，将业务数据表的元组打散存储到各个数据节点(DataNode)上，通过并行利用各个数据节点的IO能力提升数据扫描的效率。为了优化高频关联小表的查询性能，GuassDB(DWS)支持复制的数据分布方式。表的分布方式取决于表的业务属性，事实表一般数据量较大，且数据增加或者变化很频繁，建议使用散列分布；维度表数据量较小，且数据一般不会变化，只有定期更新操作，建议使用复制分布。散列分布是按照某种散列规则，把表数据map到指定的数据节点(DataNode)上进行存储的方式。散列分布可以利用各个节点的IO资源，提升各个数据节点的IO能力。GaussDB(DWS)中采用hash的散列策略，按照表定义时指定的分布列组合，对一条记录的某一个或几个字段进行hash运算后，生成对应的hash值，然后根据DN实例与哈希值的映射关系获得该元组的目标存储位置。对于散列分布的表，分布列的选择非常重要。当分布列选择合理时，Hash散列策略可以大大减小计算节点之间的数据交互，大幅提升查询性能；但是当hash分布列选择不合理时，会导致数据倾斜(某个或者某些DataNode的数据量严重超过其它DataNode的数据量)，因为短板效应导致集群的有效容量下降。散列主要使用于客户业务表，这些表有数据量大、数据量逐渐增加的特征，适用散列分布可以有效的提升表查询性能。复制分布(replication)策略将表中的全量数据在集群的每一个DN实例上保留一份。在关联操作中复制表可以避免数据重分布操作，减小网络开销，同时减少了plan segment(每个plan segment都会起对应的线程)的个数；但是复制分布策略会导致比较严重的数据冗余，因此只有小表才适合复制分布策略。实际生产上只有小数据量、查询频繁、更新(DELETE/INSERT/UFPATE)很少的表(基本都是维度表)才会定义replication分布策略。Hash分布表的分布列选取至关重要，需要满足以下原则：a)  列值应比较离散，以便数据能够均匀分布到各个DN分布列值分布不均匀会导致数据在数据节点分布不均匀(某些DataNode上数据量大，某些DataNode上数据量小)，这会导致不同DataNode上数据扫面的计算量不均衡，从而拖慢整个表扫描的性能；同时会因为部分DataNode的磁盘容量提前爆满，集群只读，导致集群有效容量下降。通常情况下使用表的主键列或者唯一索引列作为表的分布列是一个不错的选择b)  考虑选择查询中的连接条件为分布列GaussDB(DWS)的散列策略是hash，根据GaussDB(DWS)的分布式查询框架，当两表等值关联(join)列刚好是表的分布列时(如果分布列是多列，那么要求所有列都存在等值关联条件)，join任务可以不再数据重分布的情况下直接Join，这样可以省去数据重分布的时间开销和网络资源开销，从而提升查询计算性能。c)  在满足前面两条原则的情况下尽量不要选取存在常量等值filter的列GaussDB(DWS)会协调节点(Coordinator)上进行任务规划，此时会根据表的过滤条件(Filter)进行扫面操作剪枝优化，以较小IO资源开销。如果表dwcjk的分布列是zqdh，且表dwcjk扫描时存在Filter条件zqdh=’000001’，而根据散列策略zqdh=’000001’的值都分布在数据节点DN1上，那么协调节点(Coordinator)上进行任务规划时会对dwcjk表的扫描操作进行剪枝(指定只有在数据节点DN1对表dwcjk进行数据扫描操作)。这样对于表扫描的实际压力会值落在节点DN1，导致不同数据节点的IO压力不均衡。注意此策略主要适用于统计分析类的重查询场景，对于详单查询等以点查为主要场景的查询类业务，在满足前两个约束的前提下，可以优选存在常量等值Filter约束列作为分布列。因为这种场景在数据节点上使用索引加速查询，查询耗时往往以ms或者几十ms计，通过剪枝把查询任务map到具体的某个数据节点上执行，节省无效操作(不用连接到所有的数据节点上操作)，同时也会大大的提高并发能力。GaussDB(DWS)的列存储格式的表不支持主键和唯一约束，行存储格式表支持主键和唯一约束。但是存储格式表的主键和唯一约束的创建存在严格约束：分布列的集合是主键列或者索引列的子集。多个列作为分布列时，分布列的顺序会影响数据分布，即同一条记录在distribute by hash(col1, col2)方式下，跟在distribute by hash(col2, col1)分布方式下可能会map到不同的DataNode上进行存储。GaussDB(DWS)对分布列的个数没有限制，但是建议分布列的个数尽量少，一方面可以减小数据map到不同DN的计算开销，同时也可以更好的全匹配join条件，提升查询性能。转载：https://mp.weixin.qq.com/s/DgKx4kZngASQyOytn7Ve1w

GaussDB(DWS)是企业级的大规模并行处理关系型数据库，采用采用Shared-nothing架构的MPP(Massive Parallel Processing)系统，支持PB级别数据量的处理，适用于详单查询、数据仓库、混合负载和大数据分析等场景。Shared-nothing架构天然支持数据打散分布到各个数据节点(DataNode)以及多节点协同计算机制，同时这种机制对表定义涉及提出了更高的诉求，表定义会直接影响集群的有效容量以及业务查询性能。本文从产品架构、功能实现以及业务特征的角度阐述GaussDB(DWS)的中表定义需要关注的一些关键因素。1、存储方式设计 GaussDB(DWS)支持行存储(row-based storage)和列存储(column-based storage)两种存储方式，这两种存储格式分别适用不同的业务场景。通常来讲典型的点查询为主的场景推荐使用行存储，典型的统计分析型业务推荐使用列存储。行存储模式下，一条数据的所有列组合在一起称之为一个tuple多个tuple组成一个page，所有的page构成表的数据文件。pages是行存数据存取的最小单元，一个page默认8KB。page的基本结构如下：行存储模式下，所有数据列集中存储在一个tuple中，所以行存储的更新(UPDATE)、删除(DELETE)、索引点查性能较好，但是当查询列只涉及所有列的很少一部分的时候，所有列的数据也都会被读取，导致大量的无效IO，因此推荐比较简单点查场景或者存在频繁的数据更新的业务采用行存储。列存储下把数据表中的每一列单独存储，每个列的 6w条数据组成一个CU，每个列的所有的CU构成一个列的数据文件，每个列都会有单独的数据文件。CU的基本结构如下：列数据之间具有更高的相似度，所以列存储的压缩性能更好。当只查询少量列且查询数据量较大时，列存储的IO性能收益很明显。因为数据分列存储，导致更新(UPDATE)、删除(DELETE)、索引点查性的时候需要访问或者刷新更多的文件，导致大量的随机IO；因此相比行存储，列存储的更新、删除、索引点查询的性能较差。同时列存储天然的可以跟向量化执行引擎对接，在表关联、汇聚等重计算场景下可以使用向量化执行引擎提升计算性能，因此统计分析等重IO和重计算型业务推荐使用列存储。表的存储类型是表定义设计的第一步，客户业务属性是表的存储类型的决定性因素。根据以上我们对行存储和列存储原理的介绍，重查询分析(大量的多表关联、group by操作)场景推荐使用使用列存表，典型的有数仓场景；以点查询为主的场景推荐使用行存表，典型的有详单查询场景。GaussDB(DWS)支持单个database中同时存储行存储和列存储类型的表，以更好的支持混合负载场景。转载：https://mp.weixin.qq.com/s/DgKx4kZngASQyOytn7Ve1w

多列/单列统计信息未收集       优化器依赖于表的统计信息来生成合理的执行计划。如果没有及时对表中各列收集统计信息，可能会影响优化器的判断，从而生成较差的执行计划。如果生成计划时发现某个表的单列或多列统计信息未收集，warning字段会给出如下告警信息：Statistic Not Collect:schemaname.tablename(column name list)       此外，如果表格的统计信息已收集过（执行过analyze），但是距离上次analyze时间较远，表格内容发生了很大变化，可能使优化器依赖的统计信息不准，无法生成最优的查询计划。针对这种情况，可以用pg_total_autovac_tuples系统函数查询表格中自从上次分析以来发生变化的元组的数量。如果数量较大，最好执行一下analyze以使优化器获得最新的统计信息。◇SQL未下推       执行计划中的算子，如果能下推到DN节点执行，则只能在CN上执行。因为CN的数量远小于DN，大量操作堆积在CN上执行，会影响整体性能。如果遇到不能下推的函数或语法，warning字段会给出如下告警信息：SQL is not plan-shipping, reason : %s◇Hash连接大表做内表       如果发现在进行Hash连接时使用了大表作为内表，会给出如下告警信息：PlanNode[%d] Large Table is INNER in HashJoin \"%s\"目前“大表”的标准是平均每个DN上的行数大于100，000，并且内表行数是外表行数的10倍以上。◇大表等值连接使用NestLoop       如果发现对大表做等值连接时使用了NestLoop方式，会给出如下告警信息：PlanNode[%d] Large Table with Equal-Condition use Nestloop\"%s\"目前大表等值连接的判断标准是内表和外表中行数最大者大于DN的数量乘以100，000。◇数据倾斜       数据在DN之间分布不均匀，可导致数据较多的节点成为性能瓶颈。如果发现数据倾斜严重，会给出如下告警信息：PlanNode[%d] DataSkew:\"%s\", min_dn_tuples:%.0f, max_dn_tuples:%.0f目前数据倾斜的判断标准是DN中行数最多者是最少者的10倍以上，且最多者大于100,000。◇代价估算不准确         GaussDB在执行SQL语句过程中会统计实际付出的代价，并与之前估计的代价比较。如果优化器对代价的估算与实际的偏差很大，则很可能生成一个非最优化的计划。如果发现代价估计不准确，会给出如下告警信息："PlanNode[%d] Inaccurate Estimation-Rows: \"%s\" A-Rows:%.0f, E-Rows:%.0f目前的代价由计划节点返回行数来衡量，如果平均每个DN上实际/估计返回行数大于100,000，并且二者相差10倍以上，则认定为代价估算不准。◇Broadcast量过大       Broadcast主要适合小表。对于大表来说，通常采用Hash+重分布（Redistribute）的方式效率更高。如果发现计划中有大表被广播的环节，会给出如下告警信息：PlanNode[%d] Large Table in Broadcast \"%s\"目前对大表广播的认定标准为平均广播到每个DN上的数据行数大于100,000。◇索引设置不合理      如果对索引的使用不合理，比如应该采用索引扫描的地方却采用了顺序扫描，或者应该采用顺序扫描的地方却采用了索引扫描，可能会导致性能低下。索引扫描的价值在于减少数据读取量，因此认为索引扫描过滤掉的行数越多越好。如果采用索引扫描，但输出行数/扫描总行数>1/1000，并且输出行数>10000（对于行存表）或>100（对于列存表），则会给出如下告警信息：PlanNode[%d] Indexscan is not properly used:\"%s\", output:%.0f, filtered:%.0f, rate:%.5f顺序扫描适用于过滤的行数占总行数比例不大的情形。如果采用顺序扫描，但输出行数/扫描总行数<=1/1000，并且输出行数<=10000（对于行存表）或<=100（对于列存表），则会给出如下告警信息：PlanNode[%d] Indexscan is ought to be used:\"%s\", output:%.0f, filtered:%.0f, rate:%.5f◇下盘量过大或过早下盘         SQL语句执行过程中，因为内存不足等原因，可能需要将中间结果的全部或一部分转储的磁盘上。下盘可能导致性能低下，应该尽量避免。如果监测到下盘量过大或过早下盘等情况，会给出如下告警信息：•       Spill file size large than 256MB•       Broadcast size large than 100MB•       Early spill•       Spill times is greater than 3•       Spill on memory adaptive•       Hash table conflict      下盘可能是因为缓冲区设置得过小，也可能是因为表的连接顺序或连接方式不合理等原因，要结合具体的SQL进行分析。可以通过改写SQL语句，或者HINT指定连接方式等手段来解决。使用自诊断视图功能，需要将以下变量设成合适的值：▲ use_workload_manager（设成on，默认为on）▲ enable_resource_check（设成on，默认为on）▲ resource_track_level（如果设成query，则收集query级别的信息，如果设成operator，则收集所有信息，如果设成none，则以用户默认的log级别为准）▲ resource_track_cost（设成合适的正整数。为了不影响性能，只有执行代价大于resource_track_cost语句才会被收集。该值越大，收集的语句越少，对性能影响越小；反之越小，收集的语句越多，对性能的影响越大。）       执行完一条代价大于resource_track_cost后，诊断信息会存放在内存hash表中，可通过pgxc_wlm_session_history或gs_wlm_session_history视图查看。      视图中记录的有效期是3分钟，过期的记录会被系统清理。如果设置enable_resource_record=on，视图中的记录每隔3分钟会被转储到gs_wlm_session_info表中，因此3分钟之前的历史记录可以通过gs_wlm_session_info表或pgxc_wlm_session_info视图查看。转载：https://mp.weixin.qq.com/s/iQpGi2AESU16ED91-7q04g

1、 分布式架构说到分布式计划就不得不提到数据库的分布式架构，当前数据库分布式架构主要有Shared Nothing和Shared Disk两种： Shared Disk：各处理单元共享数据磁盘系统但私有CPU和Memory资源，可通过增加节点来提高并行处理的能力，扩展能力较好，但是当存储器接口达到饱和的时候，增加节点并不能获得更高的性能。业界代表Oracle Rac。 Shared Nothing：各处理单元都有自己私有的CPU/内存/硬盘等，不存在共享资源，各处理单元之间通过协议通信，并行处理和扩展能力更好。业界代表Teradata。GaussDB(DWS)基于Shared Nothing架构，继承了该架构良好的并行处理和扩展能力，但是也因数据分布存储不共享的特点，计划的生成需要面对数据倾斜、节点间数据交互等常见问题，生成的计划相对复杂。2、分布式计划2.1 计划种类： GaussDB(DWS)中当前主要存在三类分布式计划， FQS(fast query shipping)计划、Stream计划以及Remote-Query计划，其中前两类都可称之为下推计划，执行性能一般较好，而Remote-Query计划是前两类计划都无法生成情况下的最后选择，执行性能一般较差。各类计划介绍如下表，其中CN(Coordinator Node)表示数据库全局SQL解析优化节点又称协调节点，DN(Data Node)表示数据库数据存储节点也是计算单元。计划种类 执行原理 子场景 适用场景 FQS计划 CN直接将原语句下发到DN，各DN单独执行，并将执行结果在CN上进行汇总。 整个SQL下发所有DN（典型场景） 各DN执行时无数据交互。 整个SQL下发单个DN（Lightproxy场景） 单DN能完全执行出结果，常见于TP点查场景。 Stream 计划 CN根据原语句生成计划并将计划下发给DN进行执行，各DN执行过程中使用Stream算子进行数据交互。 全部计划下发DN执行（全部下推） 各DN执行时有数据交互，常见于AP复杂语句场景。 部分计划下发DN执行（部分下推） 常见于子查询可下推，父查询存在不下推因素场景。 Remote-Query 计划 CN生成计划后，将部分原语句下发到DN，各DN单独执行，执行后将结果发送给CN，CN执行剩余计划。 仅当前单场景 不满足FQS和STREAM计划的极端场景，性能较差。可能有人会有疑问，既然前面说Remote-Query是性能最差的计划，那为什么还要生成这种计划？主要是因为存在一些因素会导致执行算子无法在分散到各个DN分别执行而只能在CN上来统一执行，否则执行结果会出现错误。这些因素常被称之为不下推因素，最常见的不下推因素有不支持下推的函数和不支持下推的语法。 1）不下推因素之函数 数据库函数有两个关键属性provolatile和proshippable共同决定函数是否可以下推，其中provolatile属性的取值范围主要有IMMUTABLE、STABLE、VOLATILE三种： IMMUTABLE：简单来讲，如果一个函数对于同样的输入，一定有相同的输出，那么这类函数就是IMMUTABLE的，例如绝大部分的字符串处理函数。 STABLE：如果一个函数的返回结果在一个SQL语句的调用过程中，结果是相同的，那么他就是STABLE的。例如时间相关的处理函数，这类函数都是STABLE的。 VOLATILE：如果一个函数的返回结果可能随着每一次的调用而返回不同的结果。例如nextval，random这种函数，每次调用结果都是不可预期的。 根据属性的介绍可以看到，IMMUTABLE/ STABLE属性的函数是比较稳定的，也就是对于相同的输出，输出的结果比较固定，这类函数分散到不同的DN执行，结果也不会有多大变化，而VOLATILE函数则不行，所以绝大部分的IMMUTABLE/ STABLE属性函数是可以下推的，VOLATILE函数则不能下推，具体下推情况如下表：需要注意的是当我们创建自定义函数时，默认的provolatile属性是volatile的， proshippable属性是false，也就是函数默认不下推，如果希望将函数定义为下推函数一定要清楚的理解这两个属性的含义，否则不能下推的函数下推了会导致执行结果的错误。转载：https://mp.weixin.qq.com/s/c2Dsu-wozD7zacaaiXSknA

大规模数据变化 大规模数据导入/UPDATE/DELETE等操作，会导致表数据行数变化，新增的大量数据也会导致数据特征发生大的变化，此时需要对表重新收集统计信息。查询新增数据 常见于业务表新增数据查询场景，这个也是收集业务中最常见、最隐蔽的统计信息没有及时更新的问题，这种场景最主要的特征如下 存在一个按照时间增长的业务表 业务表每天入库新一天的数据 数据入库之后查询新增数据进行数据加工分析 在最后步骤的数据加工分析时，最长的方法就是使用Filter条件从分区表中筛选数据，如passtime > ‘2020-01-19 00:00:00’ AND pastime < ‘2020-01-20 00:00:00’，假如新增数据入库之后没有做analyze，优化器发现Filter条件中的passtime取值范围超过了统计信息中记录的passtime值的上边界，会把估算满足passtime > ‘2020-01-19 00:00:00’ AND pastime < ‘2020-01-20 00:00:00’的tuple个数为1条，导致估算行数验证失真。

显式收集统计信息单列统计信息 通过如下命令收集单列统计信息： { ANALYZE | ANALYSE } [ VERBOSE ]  [ table_name [ ( column_name [, ...] ) ] ]; 如语法描述，我们支持对指定列做统计信息，但是实际上我们很难统计实际业务SQL中到底使用了当前哪些表的列进行了代价估算，因此建议通常情况下对全表收集统计信息。扩展统计信息 通过如下命令收集多列统计信息： {ANALYZE | ANALYSE} [ VERBOSE ] table_name (( column_1_name, column_2_name [, ...] )); 需要注意的是，当前只支持在百分比采样模式下生成扩展统计信息，因此在收集扩展统计信息之前请确保GUC参数default_statistics_target为负数提升统计信息质量 analyze是按照随机采样算法从表上采样，根据样本计算表数据特征。采样数可以通过配置参数default_statistics_target进行控制，default_statistics_target取值范围为-100~10000，默认值为100。1） 当default_statistics_target > 0时；采样的样本数为300*default_statistics_target，default_statistics_target取值越大，采样的样本也越大，样本占用的内存空间也越大，统计信息计算耗时也越长2） 当default_statistics_target < 0时，采样的样本数为 (default_statistics_target)/100*表的总行数，default_statistics_target取值越小，采样的样本也越大。但是default_statistics_target < 0时会把采样数据下盘，不存在样本占用的内存空间的问题，但是因为样本过大，计算耗时长的问题同样存在 default_statistics_target < 0时，实际采样数是(default_statistics_target)/100*表的总行，所以我们又称之为百分比采样。自动收集统计信息 当配置参数autoanalyze打开时，查询语句走到优化器发现表不存在统计信息，会自动触发统计信息收集，以满足优化器的需求。以文档的case为列 注：只有对统计信息敏感的复杂查询动作(多表关联等操作)的SQL语句执行时才会触发自动收集统计信息；简单查询(比如单点，单表聚合等) 不会触发自动收集统计信息。

数据库执行SQL语句的时候，会把执行拆分为若干步骤，如下SQL select * from t1 join t2 on t1.a=t2.b where t1.b = 2 and t2.a = 3; 在具体执行的时候会拆分为表扫描和表关联两个主要查询动作。这两个查询动作都存在多种执行方式，比如表扫描均存在SeqScan、IndexScan、IndexOnlyScan、BitmapScan等多种执行方式、表关联存在NestLoop、HashJoin、MergeJoin三种执行方式，那么在具体的业务场景下什么样的查询动作才是代价最小的执行方式，这就是优化器的核心工作。 CBO主要工作原理是通过代价模型(Cost Model)和统计信息估算每种执行方式的代价，然后选择一种执行代价最优的执行方式。这里面代价模型是核心算法逻辑，统计信息是cost计算的数据源，二者配合完成cost计算；如果统计信息缺失，计算时代价模型会使用默认值来计算cost，当然这时cost会跟真实值存在较大偏差，大概率会出现选择非最优执行计划的情况，因此统计信息是CBO模型中 cost计算的数据输入，是CBO最核心的科技之一。

词法&语法解析按照约定的SQL语句规则，把输入的SQL语句从字符串转化为格式化结构(Stmt)，如果SQL语句存在语法错误，都会在这个环节报错。语义解析语义解析类似一个翻译器，把外部输入的可视化的对象翻译为数据库内部可识别的对象（比如把Stmt中以字符串记录的表名称转化为数据库内部可识别的oid），如果语句存在语义错误(比如查询的表对象不存在)，数据库会在这个环节报错。  查询重写根据规则将“语义解析”的输出等价转化为执行上更为优化的结构，比如把查询语句中的视图逐层展开至最低层的表查询。查询优化数据库确认SQL执行方式、生成执行计划的过程查询执行根据执行计划执行SQL并输出结果的过程 整个执行流程中，优化器决定了查询语句的具体执行方式，对SQL语句的性能起着关键性的作用。数据库查询优化器分为两类：基于规则的优化器(Rule-Based Optimizer，RBO) 和基于代价的优化器(Cost-Based Optimizer，CBO)。RBO是一种基于规则的优化，对于指定的场景采用指定的执行方式，这种优化模型对数据不敏感；SQL的写法往往会影响执行计划，不了解RBO的细则的人员开发的SQL性能不可控，因此RBO逐渐被抛弃，目前GaussDB等数据库厂商的优化器都是CBO模型。CBO模型是根据SQL语句生成一组可能被使用的执行计划，并估算出每种执行计划的代价，最终选择选择一个代价最小的执行方式。

SQL执行计划是一个节点数，显示执一条SQL语句执行时的详细步骤。每一个步骤是一个数据库运算符，也叫作一个执行算子。使用explain命令可以查看优化器为每个查询生成的具体执行计划。EXPLAIN的语法其中，option中COSTS与NODES的默认值为ON，其他参数默认为OFF。    说明：EXPLAIN + QUERY并不会真正执行，只会将计划打印出来，指定option中的ANALYZE可以进行实际执行PERFORMANCE 选项默认会将所有的选项置为ON，即显示所有的执行信息。CPU/BUFFER/DETAIL 选项依赖于ANALYZE，只有ANALYZE置为ON的时候，才能使用这几个选项。DETAIL选项用来控制输出，DETAIL 置为ON时，会显示各个DN上具体的执行信息；DATAIL 置为OFF时，显示所有DN的汇总信息，即最大最小值信息。EXPLAIN显示格式GaussDB中提供了两种显示格式（normal/pretty），通过设置参数explain_perf_mode进行控制。其中，normal格式为默认的显示格式。normal格式如下：pretty格式如下：改进后的显示格式，层次清晰，计划包含了plan node id，性能分析会更加简单直接。使用之前可以使用show explain_perf_mode;来查看当前数据库使用的显示风格。同时可以使用set explain_perf_mode=pretty/normal;来设置输出的格式。转载：https://mp.weixin.qq.com/s/UU04YBWVsBkEK_Smfdn6Qg

执行计划(又称解释计划)是数据库执行SQL语句的具体步骤，例如通过索引还是全表扫描访问表中的数据，连接查询的实现方式和连接的顺序等。如果 SQL 语句性能不够理想，我们首先应该查看它的执行计划。本文主要介绍如何如何详细解读GaussDB(DWS)产生的分布式执行计划，从计划中发现性能调优点。1、执行算子介绍下面重点介绍下基于sharing nothing的分布式计划中最重要的一类算子——STREAM算子1、  三种类型的stream算子Gather Stream (N:1) – 每个源结点都将其数据发送给目标结点        Redistribute Stream (N:N) – 每个源节点将其数据根据连接条件计算Hash值，根据重新计算的Hash值进行分布，发给对应的目标节点        Broadcast Stream (1:N) – 由一个源节点将其数据发给N个目标节点        其中1）主要用于CN与DN间的数据交换，2）与3）主要用于DN间的数据交换

整体调优思路通过前面对SQL语句执行流程的介绍，我们可以知道，性能瓶颈可能发生在CN端、DN端，以及结果集返回，驱动数据处理等环节，性能调优的第一步就是定位瓶颈点主要发生在哪个环节。由于GaussDB DWS大数据量处理时，大部分执行时间消耗在DN端，故本博文主要针对DN端语句执行进行总体调优思路的分享。谈到执行性能，其实从数据模型建模、集群部署、表结构设计，到最终的SQL语句优化，都与之紧密相关，如上图所示，我们使用金字塔来描述整个调优过程。越接近塔尖，其对于整个业务性的影响范围越广，需要调优时，调优成本也越高，所以在设计之初需要投入足够精力，从上至下，我们需要全面的设计，才能减少在最终SQL调优时返工的可能。整个调优过程其实是一个不断迭代的过程，如上图所示。即使设计再严密，也有可能出现SQL语句性能的优化需要导致数据建模更改、集群部署、表分布键调整的情况，这时一发动全身将引起较高的成本，同时会对其它已经调优完毕的SQL产生影响，导致重新调优，成本较高。我们统一将前三阶段归结为静态调优，将SQL语句级调优归结为执行态调优。下面重点来探讨执行态调优-SQL语句调优，从调优步骤来看可以分为性能瓶颈诊断、性能原因分析和调优项实施，从调优实施对象来看，可能包括前面提到的数据建模、集群部署、表结构设计方面的修改，SQL语句层调优可以分为系统级调优和语句级调优。当然，有一些调优项，例如系统调优项，可以作为经验固化下来，在集群部署的时候就一并设置好，减少这方面调优花费的成本。同时，SQL调优也是一个迭代的过程，在实施一次调优项后，需要继续重新进行调优分析，直至性能达到标准为止。后面的章节，将围绕调优步骤和SQL层的调优项来开展。性能瓶颈诊断 GaussDB DWS提供了丰富的计划信息显示工具Explain，以及动态执行信息分析工具Top SQL。 Explain工具主要针对单个语句进行展示，可以使用explain命令显示CN生成的SQL语句的计划，也可以使用explain analyze/performance命令显示执行态信息。通过执行态信息，我们可以分析出算子为单位的性能，也可以分析出算子内部各步骤的性能，进一步为诊断性能的瓶颈打下了基础。Explain工具相关内容请参考博文《GaussDB(DWS)性能调优系列基础篇二：大道至简explain计划信息》。 Top SQL工具则针对集群中运行的语句进行整体性能分析，其包含12个视图，可以将执行时间超过一定设置阈值的语句的执行状态、执行结果进行实时查询，同时可以设置将其转储用作后续分析。附加于该工具之上的SQL自诊断调优工具，则通过瓶颈点的分析，给出可能的性能原因分析。同时，我们还提供Unique SQL工具，进行一类SQL的性能持续跟踪，可以用于发现系统资源及硬件问题对SQL性能产生的影响。性能原因分析属于性能调优里的高阶知识了，通常要对数据库的执行实现原理有基本了解才能够逐步深入下去。本章节将深入浅出地介绍数据库执行实现原理的基本技术，帮助各位读者朋友能够有兴趣去主动查找性能产生的原因，从而自己找到性能调优的方法。 前面已经对GaussDB DWS的执行流程进行了介绍，由CN生成执行计划下发到DN去执行。GaussDB DWS是基于代价来生成计划的，因此需要依据基表的统计信息，进行每一步结果集统计信息的估算，根据数据规模的场景从GaussDB DWS支持的备选算子中选择最优的算子组合成计划进行执行。因此，统计信息是计划准确的前提，在执行SQL语句前要确保收集最新的统计信息，有关统计信息的收集可以参见博文《GaussDB(DWS)性能调优系列基础篇一：万物之始analyze统计信息》。 由于统计信息只包含基表的统计信息，表关联之后的统计信息只能通过估算得到，因此仍然可能存在估算不准的情况。GaussDB DWS针对不同的SQL语句中的操作，为每个操作内部实现了不同的算子。每个算子可能在部分场景下是占优的，但其它场景比较差。SQL优化时，根据具体的场景去自动匹配最优的算子。如果存在估算不准，将导致算子选择出现失误，从而计划较差，此时就需要根据计划的瓶颈来分析具体的原因了。转载：https://mp.weixin.qq.com/s/LhpNOoKjOrf7PrGeJ6tMcw

本篇博文作为《GaussDB(DWS)性能调优系列》的专题文章，主要介绍数据库级别的性能调优思路和总体策略，包括系统级和语句级调优。同时，《GaussDB(DWS)性能调优系列》文章分为基础篇和实战篇，各位读者在通过基础篇文章了解数据库的基本原理后，可以结合调优思路，对实战篇的各个调优技巧进行深入的学习。有关整个调优过程中的其它方面，后续论坛会推出其它博文进行介绍。GaussDB DWS是典型的share-nothing架构，其计算组件的示意图如上图所示，主要由CN（Coordinator）和DN（DataNode）组成。CN是整个集群的协调者，是整个集群与应用进行连接处理的门户，用于接收客户的SQL语句并返回执行结果。DN是集群进行数据计算的主体，各个DN拥有独立的存储和计算资源，使得各个DN可以独立地进行计算。GaussDB DWS支持多CN架构，通常应用程序会通过LVS（负载均衡设备）将语句均匀分发到各个CN上，以减少单个CN的瓶颈作用。GaussDB DWS的SQL处理流程如上方右图所示，其包含以下几个主要步骤：（1）CN通过驱动或客户端接收到一条SQL后，会进行解析、优化，并最终返回执行结果；（2）CN进行优化后，生成相应的执行计划；（3）CN将相同的执行计划下发到各个DN进行执行；（4）如果DN之间需要进行数据交换，则执行计划中包含流操作算子Stream，DN之间同步通过Stream算子进行数据交换，共同完成计划的执行并向CN返回结果。同时，GaussDB DWS对于不需要DN间数据交换的语句，还支持语句下发到DN生成计划；对于部分不支持分布式查询的语句，生成不能下推的计划（此计划对于大数据量性能较差）。转载：https://mp.weixin.qq.com/s/LhpNOoKjOrf7PrGeJ6tMcw