文档名称
上，那么只能使用HDFS表（对应Elk产品）。
对于每种存储方式还有对应的存储层优化手段，这部分会在后续的调优章节深入介绍
优化手段之guc参数
查询优化的主要是目的为查询语句选择高效的执行方式。 如下SQL语句:
select count(1)
from customer inner join store_sales on (ss_customer_sk = c_customer_sk);
在执行customer inner join store_sales的时候，GaussDB 200支持nestloop、mergejoin和hashjoin三种不同的join方式。优化器会根据表customer和表store_sales的统计信息估算结果集的大小以及每种jion方式的执行代价，然后对比选出执行代价最小的执行计划。
但是我们前面介绍过， 执行代价计算都是基于一定的模型和统计信息进行估算，当因为某些原因代价估算不能反映真实的cost的时候，我们就需要通过guc参数设置的方式让执行计划倾向更优规划。
优化手段之SQL重写
根据数据库的SQL执行机制以及大量的实践，我们发现在一些场景下，在保证客户业务SQL逻辑的前提的下，通过一定规则调整SQL语句可以大幅度的提升SQL语句的性能
这种调优场景对DBA的要求比较高，需要对客户业务有足够的了解，同时也需要扎实的SQL语句基本功，后续会介绍几个常见的SQL改写场景。
2.2 执行计划解读
执行计划概述
查询计划是一个执行节点树，显示执行一条SQL语句时必须执行的详细步骤，每一个步骤为一个数据库运算符，这些运算符将被用来生成执行计划。最底层的节点是表扫描节点，它扫描表并返回原始数据行。不同的表访问模式有不同的扫描节点类型：顺序扫描、索引扫描等。也有非表行来源，如VALUES子句和返回行集的函数，它们有自己的扫描节点类型。
如果查询需要连接、聚集、排序、或者对原始行的其它操作，那么就会在扫描节点“之上”添加
2024-4-30 第5页, 共42页
文档名称
其它节点来。 并且这些操作通常都有多种方法，因此在这些位置也有可能出现不同的执行节点类型。
我们可以使用EXPLAIN命令察看优化器为每个查询生成的具体执行计划，EXPLAIN给规划树中每个执行节点都输出一行，显示基本的节点类型和优化器为执行这个规划节点预计的开销值。第一行(最上层节点)是对该规划的总执行开销的预计。这个数值就是优化器试图最小化的数值。
执行计划解读
GaussDB 200 OLAP对执行计划提供了normal、pretty、summary、run四种展示方式，可以通过设置GUC参数explain_perf_mode显示不同格式的执行计划，本文所有用例默认显示 pretty格式。
以如下SQL语句为例：
select cjxh, count(1) from dwcjk group by cjxh; 执行explain输出为：
图中
id：执行算子节点编号
operation：具体的执行结算子名称 E-rows：每个算子估算的输出行数 E-costs：每个算子估算的执行代价 width：每个算子输出元组的宽度 注：
1. E-costs是优化器根据成本参数定义的单位来衡量的，习惯上以磁盘页面抓取为1个单位2024-4-30
第6页, 共42页
文档名称
单位， 其它开销参数将参照它来设置
2. 每个节点的开销（E-costs值）包括它的所有子节点的开销
3. 这个开销只反映优化器关心的东西，并没有把结果行传递给客户端的时间考虑进去 4. Vector前缀的算子是指向量化执行引擎算子，一般出现含有列存表的Query中 5. Streaming是一个特殊的算子，它实现了分布式架构的核心数据shuffle功能，Streaming
共有三种形态，分别对应了分布式结构下不同的数据shuffle功能： a) Streaming (type: GATHER)：
作用是coordinator从DataNode收集数据 b) Streaming(type: REDISTRIBUTE)
作用是DataNode根据选定的列把数据重分布到所有的DataNode c) Streaming(type: BROADCAST)
作用是把当前DataNode的数据广播给其他所有的DataNode
上述执行计划中
1. 第一层：CStore Scan on dwcjk
表扫描算子，用Cstore Scan的方式扫描表dwcjk。这一层的作为把表dwcjk的数据从buffer或者磁盘上读上来输送给上层节点参与计算 2. 第二层：Vector Hash Aggregate
聚合算子，作用是把下层计算输送上来的算子做聚合操作(group by)。 3. 第三层：Vector Streaming (type: GATHER)
Shuffe算子，此处GATHER类型的Shuffe算子作用是把数据从DataNode节点汇聚到Coordinator节点 4. 第四层：Row Adapter
存储格式转化算子，主要作用是把内存中列式格式数据转为行式数据，以便客户端展示
需要注意的是部分场景(最上面算子的为Data Node Scan)下需要设置enable_fast_query_shipping为false才能看到具体的执行计划，如下面这个计划：
2024-4-30
第7页, 共42页
文档名称
设置enable_fast_query_shipping参数之后，执行计划显示如下：
执行信息解读
在优化的过程我们经常需要执行explain analyze/performance(两者都会实际执行SQL语句并返回执行信息，explain performance可以看做是explain analyze的升级版，后者相对于前者来说增加了每个DataNode上的执行信息)来查看执行计划实际执行的情况，通过实际的执行情况与优化器的估算之间的差别为我们的优化提供依据。 以如下SQL语句为例：
select count(1) from dwcjk group by cjxh; 执行explain performance输出为：
2024-4-30
第8页, 共42页
文档名称
图中显示执行信息分为以下5个部分
1. 以表格的形式将计划显示出来，包含有8个字段，分别是
a) id、operation、E-rows、E-costs、width和explain的含义一致 b) Peak Memory：此算子在每个DataNode上执行时使用的内存峰值 2024-4-30
第9页, 共42页
GaussDB 200 性能调优
