摘要： 性能调优是应用迁移或开发过程当中的关键步骤，同时也在整个项目实施过程当中占据很大的分量，本篇主要介绍数据库级别的性能调优思路和整体策略。
性能调优是应用迁移或开发过程当中的关键步骤，同时也在整个项目实施过程当中占据很大的分量，在不少实施步骤中都须要进行考虑，从开始的数据建模，表定义的设计，到数据库硬件、集群部署的选择，再到数据库系统级调优、数据表结构设计，以及单个SQL语句的编写及调优，都要考虑对性能的影响。数据库
同时，性能调优一般没有明确的衡量标准，没有明确的对错之分，一般须要的隐式技能比较多，使得其的技术含金量得以提高。一般来看，要作到一个性能调优的高手，除了对于应用程序的逻辑作到游刃有余外，还须要对应用的数据库的基本实现原理有所了解，更甚者，还须要对操做系统、网络等基础知识有所涉猎，同时还要具有性能诊断和分析技巧。固然，性能调优是一个不断积累的过程，你们不用考虑一步到位，惟有进行实践的积累，才能在广阔的调优战场所向披靡。网络
本篇博文做为《GaussDB(DWS)性能调优系列》的专题文章，主要介绍数据库级别的性能调优思路和整体策略，包括系统级和语句级调优。同时，《GaussDB(DWS)性能调优系列》文章分为基础篇和实战篇，各位读者在经过基础篇文章了解数据库的基本原理后，能够结合调优思路，对实战篇的各个调优技巧进行深刻的学习。有关整个调优过程当中的其它方面，后续论坛会推出其它博文进行介绍。架构
1. 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生成计划；对于部分不支持分布式查询的语句，生成不能下推的计划（此计划对于大数据量性能较差）。各类计划的对比可详见博文《GaussDB(DWS)性能调优系列基础篇三：衍化至繁之分布式计划详解》。本文后续的讨论均基于Stream计划。分布式
2. 总体调优思路
经过前面对SQL语句执行流程的介绍，咱们能够知道，性能瓶颈可能发生在CN端、DN端，以及结果集返回，驱动数据处理等环节，性能调优的第一步就是定位瓶颈点主要发生在哪一个环节。因为GaussDB DWS大数据量处理时，大部分执行时间消耗在DN端，故本博文主要针对DN端语句执行进行整体调优思路的分享。工具
谈到执行性能，其实从数据模型建模、集群部署、表结构设计，到最终的SQL语句优化，都与之紧密相关，如上图所示，咱们使用金字塔来描述整个调优过程。越接近塔尖，其对于整个业务性的影响范围越广，须要调优时，调优成本也越高，因此在设计之初须要投入足够精力，从上至下，咱们须要全面的设计，才能减小在最终SQL调优时返工的可能。oop
整个调优过程实际上是一个不断迭代的过程，如上图所示。即便设计再严密，也有可能出现SQL语句性能的优化须要致使数据建模更改、集群部署、表分布键调整的状况，这时一发动全身将引发较高的成本，同时会对其它已经调优完毕的SQL产生影响，致使从新调优，成本较高。性能
咱们统一将前三阶段归结为静态调优，将SQL语句级调优归结为执行态调优。下面重点来探讨执行态调优-SQL语句调优，从调优步骤来看能够分为性能瓶颈诊断、性能缘由分析和调优项实施，从调优实施对象来看，可能包括前面提到的数据建模、集群部署、表结构设计方面的修改，SQL语句层调优能够分为系统级调优和语句级调优。固然，有一些调优项，例如系统调优项，能够做为经验固化下来，在集群部署的时候就一并设置好，减小这方面调优花费的成本。同时，SQL调优也是一个迭代的过程，在实施一次调优项后，须要继续从新进行调优分析，直至性能达到标准为止。后面的章节，将围绕调优步骤和SQL层的调优项来开展。学习
3. 性能瓶颈诊断
GaussDB DWS提供了丰富的计划信息显示工具Explain，以及动态执行信息分析工具Top SQL。大数据
Explain工具主要针对单个语句进行展现，可使用explain命令显示CN生成的SQL语句的计划，也可使用explain analyze/performance命令显示执行态信息。经过执行态信息，咱们能够分析出算子为单位的性能，也能够分析出算子内部各步骤的性能，进一步为诊断性能的瓶颈打下了基础。Explain工具相关内容请参考博文《GaussDB(DWS)性能调优系列基础篇二：大道至简explain计划信息》。
Top SQL工具则针对集群中运行的语句进行总体性能分析，其包含12个视图，能够将执行时间超过必定设置阈值的语句的执行状态、执行结果进行实时查询，同时能够设置将其转储用做后续分析。附加于该工具之上的SQL自诊断调优工具，则经过瓶颈点的分析，给出可能的性能缘由分析。同时，咱们还提供Unique SQL工具，进行一类SQL的性能持续跟踪，能够用于发现系统资源及硬件问题对SQL性能产生的影响。Top SQL工具相关内容请参考博文《GaussDB(DWS)性能调优系列实战篇二：十八般武艺之坏味道SQL识别》。
4. 性能缘由分析
性能缘由分析属于性能调优里的高阶知识了，一般要对数据库的执行实现原理有基本了解才可以逐步深刻下去。本章节将深刻浅出地介绍数据库执行实现原理的基本技术，帮助各位读者朋友可以有兴趣去主动查找性能产生的缘由，从而本身找到性能调优的方法。
前面已经对GaussDB DWS的执行流程进行了介绍，由CN生成执行计划下发到DN去执行。GaussDB DWS是基于代价来生成计划的，所以须要依据基表的统计信息，进行每一步结果集统计信息的估算，根据数据规模的场景从GaussDB DWS支持的备选算子中选择最优的算子组合成计划进行执行。所以，统计信息是计划准确的前提，在执行SQL语句前要确保收集最新的统计信息，有关统计信息的收集能够参见博文《GaussDB(DWS)性能调优系列基础篇一：万物之始analyze统计信息》。
因为统计信息只包含基表的统计信息，表关联以后的统计信息只能经过估算获得，所以仍然可能存在估算不许的状况。GaussDB DWS针对不一样的SQL语句中的操做，为每一个操做内部实现了不一样的算子。每一个算子可能在部分场景下是占优的，但其它场景比较差。SQL优化时，根据具体的场景去自动匹配最优的算子。若是存在估算不许，将致使算子选择出现失误，从而计划较差，此时就须要根据计划的瓶颈来分析具体的缘由了。
一般状况下，GaussDB处理的操做类型主要分为：扫描算子（Scan）、关联算子（Join）、汇集算子（Agg）和网络传输算子（Stream）。下表列出了各算子类别的使用场景，以及各种别中可选的算子，及其适用范围，同时列出调优场景，供你们参考。
（1）扫描算子（Scan）：主要用于处理从存储扫描数据，返回上层算子，包括：全表扫描算子、索引扫描算子，其中行列存均对应不一样的全套扫描算子，索引扫描包括：IndexScan（普通索引扫描）、IndexOnlyScan（仅扫描索引便可得到结果）、BitmapScan（须要索引扫描获取位图后再到基表上扫描），BitmapScanAnd/Or（从多个索引扫描进行位图运算后再到基表上扫描），因为索引扫描的原理基本都相同，故一并探讨。
（2）关联算子（Join）：主要用于处理表的关联操做。在数据库中，多表关联时，SQL优化会选择关联顺序进行两两关联。表关联时能够包含关联操做，也能够没有关联操做（笛卡尔积）。在GaussDB DWS中，主要包含NestLoop, HashJoin, MergeJoin三种关联算子。
（3）汇集算子（Agg）：
（4）网络传输算子（Stream）：
（5）其它算子：同时GaussDB DWS还支持排序（Sort）、集合（SetOp）、物化（Materialize）、窗口汇集（WindowAgg）和输出限制（Limit）算子，因为调优基本不涉及，故此处略过。
5. 调优项实施
在知道致使性能问题的缘由后，就能够制定调优项并开始实施了。前面已经提到，调优项实施的范围很广。本博文仅探讨数据库级的调优项，包括系统级调优和语句级调优两部分。
a)系统级调优项
系统级调优又细分为操做系统参数调优和数据库全局参数调优，一般涉及到的是系统CPU、IO、内存、网络资源的充分使用，避免资源冲突，提高整个系统查询的吞吐量。
因为数据库是运行在操做系统之上的，所以操做系统资源的利用率对于数据库性能的提高起到基石的做用。对于操做系统参数的调优，主要集中在操做系统内存参数、IO参数以及网络参数的设置上，具体可参见GaussDB DWS产品文档。
数据库级别的调优，主要也是集中在上述资源的使用上，在上述四维度有如下主要因素的考虑（具体设置方法能够参见GaussDB DWS产品文档）：
b)语句级调优项
语句级调优一般须要经过计划分析，找到性能瓶颈点，而后根据瓶颈点对应的扫描、关联、汇集、Stream等算子，分析是否属于算子适用场景，是否符合调优条件。若是是，咱们有如下调优手段：
i. 经过修改表定义，包括行列存、表的分布方式，达到减小IO和网络资源开销的目的，详见博文《GaussDB(DWS)性能调优系列实战篇三：十八般武艺之好味道表定义》。
ii. 若是最终分析是因为估算不许致使，能够经过相关GUC参数调整来设置不一样的结果集估算模型，或禁止生成某种类型的算子，经过改进估算值达到优化计划的目的，详见博文《GaussDB(DWS)性能调优系列实战篇五：十八般武艺之路径干预》。
iii.若是在迁移或升级过程当中出现计划劣化，也能够经过Plan Hint的调优方式干预优化器生成理想的计划，详见博文《GaussDB(DWS)性能调优系列实战篇六：十八般武艺Plan hint运用》。
iv.对于上述调优手段都没法解决的问题，例如：下推问题，相关子查询提高，NOT IN等问题，或者SQL语句存在计算冗余等问题，须要根据瓶颈点选择灵活多变的SQL改写策略消除瓶颈点，具体可参见博文《GaussDB(DWS)性能调优系列实战篇四：十八般武艺之SQL改写》
总的来讲，性能调优是一项艰巨的工程，固然深刻其中，学习到的知识以及得到的收获都是很是大的。后续论坛也会推出更多的博文对性能调优的方方面面进行介绍，帮助各位读者迅速积累调优的经验。