目录
Query执行流程
SQL执行计划介绍
SQL执行计划概述
详解
调优流程
更新统计信息
审视和修改表定义
审视和修改表定义概述
选择存储模型
使用局部聚簇
使用分区表
选择数据类型
典型SQL调优点
SQL自诊断
子查询调优
统计信息调优
算子级调优
经验总结：SQL语句改写规则
SQL调优关键参数调整
Query执行流程
SQL引擎从接受SQL语句到执行SQL语句需要经历的步骤如图1和表1所示。其中，红色字体部分为DBA可以介入实施调优的环节。
图 1 SQL引擎执行查询类SQL语句的流程
表 1 SQL引擎执行查询类SQL语句的步骤说明
|
步骤 |
说明 |
|---|---|
|
1、语法&词法解析 |
按照约定的SQL语句规则，把输入的SQL语句从字符串转化为格式化结构（Stmt）。 |
|
2、语义解析 |
将“语法&词法解析”输出的格式化结构转化为数据库可以识别的对象。 |
|
3、查询重写 |
根据规则把“语义解析”的输出等价转化为执行上更为优化的结构。 |
|
4、查询优化 |
根据“查询重写”的输出和数据库内部的统计信息规划SQL语句具体的执行方式，也就是执行计划。统计信息和GUC参数对查询优化（执行计划）的影响，请参见调优手段之统计信息和调优手段之GUC参数。 |
|
5、查询执行 |
根据“查询优化”规划的执行路径执行SQL查询语句。底层存储方式的选择合理性，将影响查询执行效率。详见调优手段之底层存储。 |
调优手段之统计信息
openGauss优化器是典型的基于代价的优化（Cost-Based Optimization，简称CBO）。在这种优化器模型下，数据库根据表的元组数、字段宽度、NULL记录比率、distinct值、MCV值、HB值等表的特征值，以及一定的代价计算模型，计算出每一个执行步骤的不同执行方式的输出元组数和执行代价（cost），进而选出整体执行代价最小/首元组返回代价最小的执行方式进行执行。这些特征值就是统计信息。从上面的描述可以看出统计信息是查询优化的核心输入，准确的统计信息将帮助规划器选择最合适的查询规划。一般来说我们会通过ANALYZE语法收集整个表或者表的若干个字段的统计信息，周期性地运行ANALYZE，或者在对表的大部分内容做了更改之后马上运行ANALYZE。
调优手段之GUC参数
查询优化的主要目的是为查询语句选择高效的执行方式。
如下SQL语句:
select count(1)
from customer inner join store_sales on (ss_customer_sk = c_customer_sk);
在执行customer inner join store_sales的时候，openGauss支持Nested Loop、Merge Join和Hash Join三种不同的Join方式。优化器会根据表customer和表store_sales的统计信息估算结果集的大小以及每种join方式的执行代价，然后对比选出执行代价最小的执行计划。
正如前面所说，执行代价计算都是基于一定的模型和统计信息进行估算，当因为某些原因代价估算不能反映真实的cost的时候，我们就需要通过guc参数设置的方式让执行计划倾向更优规划。
调优手段之底层存储
openGauss的表支持行存表、列存表，底层存储方式的选择严格依赖于客户的具体业务场景。一般来说计算型业务查询场景（以关联、聚合操作为主）建议使用列存表；点查询、大批量UPDATE/DELETE业务场景适合行存表。
对于每种存储方式还有对应的存储层优化手段，这部分会在后续的调优章节深入介绍。
调优手段之SQL重写
除了上述干预SQL引擎所生成执行计划的执行性能外，根据数据库的SQL执行机制以及大量的实践发现，有些场景下，在保证客户业务SQL逻辑的前提下，通过一定规则由DBA重写SQL语句，可以大幅度的提升SQL语句的性能。
这种调优场景对DBA的要求比较高，需要对客户业务有足够的了解，同时也需要扎实的SQL语句基本功，后续会介绍几个常见的SQL改写场景。
SQL执行计划介绍
SQL执行计划概述
SQL执行计划是一个节点树，显示openGauss执行一条SQL语句时执行的详细步骤。每一个步骤为一个数据库运算符。
使用EXPLAIN命令可以查看优化器为每个查询生成的具体执行计划。EXPLAIN给每个执行节点都输出一行，显示基本的节点类型和优化器为执行这个节点预计的开销值。如图1所示。
图 1 SQL执行计划示例
- 最底层节点是表扫描节点，它扫描表并返回原始数据行。不同的表访问模式有不同的扫描节点类型：顺序扫描、索引扫描等。最底层节点的扫描对象也可能是非表行数据（不是直接从表中读取的数据），如VALUES子句和返回行集的函数，它们有自己的扫描节点类型。
- 如果查询需要连接、聚集、排序、或者对原始行做其它操作，那么就会在扫描节点之上添加其它节点。 并且这些操作通常都有多种方法，因此在这些位置也有可能出现不同的执行节点类型。
- 第一行（最上层节点）是执行计划总执行开销的预计。这个数值就是优化器试图最小化的数值。
执行计划显示信息
除了设置不同的执行计划显示格式外，还可以通过不同的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查看执行计划及其实际的运行信息，以便更精准地定位问题原因。
EXPLAIN PERFORMANCE轻量化执行方式与EXPLAIN PERFORMANCE保持一致，在原来的基础上减少了性能分析的时间，执行时间与SQL执行时间的差异显著减少。
详解
如SQL执行计划概述节中所说，EXPLAIN会显示执行计划，但并不会实际执行SQL语句。EXPLAIN ANALYZE和EXPLAIN PERFORMANCE两者都会实际执行SQL语句并返回执行信息。在这一节将详细解释执行计划及执行信息。
执行计划
以如下SQL语句为例：
SELECT * FROM t1, t2 WHERE t1.c1 = t2.c2;
执行EXPLAIN的输出为：
执行计划层级解读（纵向）：
-
第一层：Seq Scan on t2
表扫描算子，用Seq Scan的方式扫描表t2。这一层的作用是把表t2的数据从buffer或者磁盘上读上来输送给上层节点参与计算。
-
第二层：Hash
Hash算子，作用是把下层计算输送上来的算子计算hash值，为后续hash join操作做数据准备。
-
第三层：Seq Scan on t1
表扫描算子，用Seq Scan的方式扫描表t1。这一层的作用是把表t1的数据从buffer或者磁盘上读上来输送给上层节点参与hash join计算。
-
第四层：Hash Join
join算子，主要作用是将t1表和t2表的数据通过hash join的方式连接，并输出结果数据。
执行计划中的关键字说明：
-
表访问方式
-
Seq Scan
全表顺序扫描。
-
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
归并连接，通常情况下执行性能差于哈希连接。如果源数据已经被排序过，在执行融合连接时，并不需要再排序，此时融合连接的性能优于哈希连接。
-
-
运算符
-
sort
对结果集进行排序。
-
filter
EXPLAIN输出显示WHERE子句当作一个“filter”条件附属于顺序扫描计划节点。这意味着规划节点为它扫描的每一行检查该条件，并且只输出符合条件的行。预计的输出行数降低了，因为有WHERE子句。不过，扫描仍将必须访问所有 10000 行，因此开销没有降低；实际上它还增加了一些（确切的说，通过10000 * cpu_operator_cost）以反映检查WHERE条件的额外CPU时间。
-
LIMIT
LIMIT限定了执行结果的输出记录数。如果增加了LIMIT，那么不是所有的行都会被检索到。
-
执行信息
以如下SQL语句为例：
复制代码select sum(t2.c1) from t1,t2 where t1.c1=t2.c2 group by t1.c2;
执行EXPLAIN PERFORMANCE输出为：
调优流程
对慢SQL语句进行分析，通常包括以下步骤：
操作步骤
- 收集SQL中涉及到的所有表的统计信息。在数据库中，统计信息是规划器生成计划的源数据。没有收集统计信息或者统计信息陈旧往往会造成执行计划严重劣化，从而导致性能问题。从经验数据来看，10%左右性能问题是因为没有收集统计信息。具体请参见更新统计信息。
- 通过查看执行计划来查找原因。如果SQL长时间运行未结束，通过EXPLAIN命令查看执行计划，进行初步定位。如果SQL可以运行出来，则推荐使用EXPLAIN ANALYZE或EXPLAIN PERFORMANCE查看执行计划及实际运行情况，以便更精准地定位问题原因。有关执行计划的详细介绍请参见SQL执行计划介绍。
- 审视和修改表定义。
- 针对EXPLAIN或EXPLAIN PERFORMANCE信息，定位SQL慢的具体原因以及改进措施，具体参见典型SQL调优点。
- 通常情况下，有些SQL语句可以通过查询重写转换成等价的，或特定场景下等价的语句。重写后的语句比原语句更简单，且可以简化某些执行步骤达到提升性能的目的。查询重写方法在各个数据库中基本是通用的。经验总结：SQL语句改写规则介绍了几种常用的通过改写SQL进行调优的方法。
更新统计信息
在数据库中，统计信息是规划器生成计划的源数据。没有收集统计信息或者统计信息陈旧往往会造成执行计划严重劣化，从而导致性能问题。
背景信息
ANALYZE语句可收集与数据库中表内容相关的统计信息，统计结果存储在系统表PG_STATISTIC中。查询优化器会使用这些统计数据，以生成最有效的执行计划。
建议在执行了大批量插入/删除操作后，例行对表或全库执行ANALYZE语句更新统计信息。目前默认收集统计信息的采样比例是30000行（即：GUC参数default_statistics_target默认设置为100），如果表的总行数超过一定行数（大于1600000），建议设置Guc参数default_statistics_target为-2，即按2%收集样本估算统计信息。
对于在批处理脚本或者存储过程中生成的中间表，也需要在完成数据生成之后显式的调用ANALYZE。
对于表中多个列有相关性且查询中有同时基于这些列的条件或分组操作的情况，可尝试收集多列统计信息，以便查询优化器可以更准确地估算行数，并生成更有效的执行计划。
操作步骤
使用以下命令更新某个表或者整个database的统计信息。--更新单个表的统计信息。 ANALYZE tablename; --更新全库的统计信息。 ANALYZE;
使用以下命令进行多列统计信息相关操作。
--收集tablename表的column_1、column_2列的多列统计信息。
ANALYZE tablename ((column_1, column_2));
--添加tablename表的column_1、column_2列的多列统计信息声明。
ALTER TABLE tablename ADD STATISTICS ((column_1, column_2));
--收集单列统计信息，并收集已声明的多列统计信息。
ANALYZE tablename;
--删除tablename表的column_1、column_2列的多列统计信息或其声明。
ALTER TABLE tablename DELETE STATISTICS ((column_1, column_2));
须知：
在使用ALTER TABLE tablename ADD STATISTICS语句添加了多列统计信息声明后，系统并不会立刻收集多列统计信息，而是在下次对该表或全库进行ANALYZE时，进行多列统计信息的收集。
如果想直接收集多列统计信息，请使用ANALYZE命令进行收集。
说明：
使用EXPLAIN查看各SQL的执行计划时，如果发现某个表SEQ SCAN的输出中rows=10，rows=10是系统给的默认值，有可能该表没有进行ANALYZE，需要对该表执行ANALY
审视和修改表定义
审视和修改表定义概述
好的表定义至少需要达到以下几个目标：
- 减少扫描数据数据量。通过分区的剪枝机制可以实现该点。
- 尽量极少随机IO。通过聚簇/局部聚簇可以实现该点。
表定义在数据库设计阶段创建，在SQL调优过程中进行审视和修改。
选择存储模型
进行数据库设计时，表设计上的一些关键项将严重影响后续整库的查询性能。表设计对数据存储也有影响：好的表设计能够减少I/O操作及最小化内存使用，进而提升查询性能。
表的存储模型选择是表定义的第一步。客户业务属性是表的存储模型的决定性因素，依据下面表格选择适合当前业务的存储模型。
|
存储模型 |
适用场景 |
|---|---|
|
行存 |
点查询（返回记录少，基于索引的简单查询）。 增删改比较多的场景。 |
|
列存 |
统计分析类查询（group 、join多的场景）。 |
使用局部聚簇
局部聚簇（Partial Cluster Key）是列存下的一种技术。这种技术可以通过min/max稀疏索引较快的实现基表扫描的filter过滤。Partial Cluster Key可以指定多列，但是一般不建议超过2列。Partial Cluster Key的选取原则：
- 受基表中的简单表达式约束。这种约束一般形如col op const，其中col为列名，op为操作符 =、>、>=、<=、<，const为常量值。
- 尽量采用选择度比较高（过滤掉更多数据）的简单表达式中的列。
- 尽量把选择度比较低的约束col放在Partial Cluster Key中的前面。
- 尽量把枚举类型的列放在Partial Cluster Key中的前面。
使用分区表
分区表是把逻辑上的一张表根据某种方案分成几张物理块进行存储。这张逻辑上的表称之为分区表，物理块称之为分区。分区表是一张逻辑表，不存储数据，数据实际是存储在分区上的。分区表和普通表相比具有以下优点：
- 改善查询性能：对分区对象的查询可以仅搜索自己关心的分区，提高检索效率。
- 增强可用性：如果分区表的某个分区出现故障，表在其他分区的数据仍然可用。
- 方便维护：如果分区表的某个分区出现故障，需要修复数据，只修复该分区即可。
openGauss支持的分区表为范围分区表。
范围分区表：将数据基于范围映射到每一个分区。这个范围是由创建分区表时指定的分区键决定的。分区键经常采用日期，例如将销售数据按照月份进行分区。
选择数据类型
高效数据类型，主要包括以下三方面：
-
尽量使用执行效率比较高的数据类型
一般来说整型数据运算（包括=、＞、＜、≧、≦、≠等常规的比较运算，以及group by）的效率比字符串、浮点数要高。比如某客户场景中对列存表进行点查询，filter条件在一个numeric列上，执行时间为10+s；修改numeric为int类型之后，执行时间缩短为1.8s左右。
-
尽量使用短字段的数据类型
长度较短的数据类型不仅可以减小数据文件的大小，提升IO性能；同时也可以减小相关计算时的内存消耗，提升计算性能。比如对于整型数据，如果可以用smallint就尽量不用int，如果可以用int就尽量不用bigint。
-
使用一致的数据类型
表关联列尽量使用相同的数据类型。如果表关联列数据类型不同，数据库必须动态地转化为相同的数据类型进行比较，这种转换会带来一定的性能开销。
典型SQL调优点
SQL调优是一个不断分析与尝试的过程：试跑Query，判断性能是否满足要求；如果不满足要求，则通过查看执行计划分析原因并进行针对性优化；然后重新试跑和优化，直到满足性能目标。
SQL自诊断
用户在执行查询或者执行INSERT/DELETE/UPDATE/CREATE TABLE AS语句时，可能会遇到性能问题。这种情况下，通过查询PG_CONTROL_GROUP_CONFIG、GS_SESSION_MEMORY_DETAIL视图的warning字段可以获得对应查询可能导致性能问题的告警信息，为性能调优提供参考。
SQL自诊断的告警类型与resource_track_level的设置有关系。如果resource_track_level设置为query，则可以诊断多列/单列统计信息未收集和SQL不下推的告警。如果resource_track_level设置为operator，则可以诊断所有的告警场景。
SQL自诊断的诊断范围与resource_track_cost的设置有关系。当SQL的代价大于resource_track_cost时，SQL才会被诊断。SQL的代价可以通过explain来确认。
告警场景
目前支持对多列/单列统计信息未收集导致性能问题的场景上报告警。
如果存在单列或者多列统计信息未收集，则上报相关告警。调优方法可以参考更新统计信息和统计信息调优。
告警信息示例：
整表的统计信息未收集：
Statistic Not Collect:
schema_test.t1
单列统计信息未收集：
Statistic Not Collect:
schema_test.t2(c1,c2)
多列统计信息未收集：
Statistic Not Collect:
schema_test.t3((c1,c2))
单列和多列统计信息未收集：
Statistic Not Collect:
schema_test.t4(c1,c2) schema_test.t4((c1,c2))
规格约束
-
告警字符串长度上限为2048。如果告警信息超过这个长度（例如存在大量未收集统计信息的超长表名、列名等信息）则不告警，只上报warning：
WARNING, "Planner issue report is truncated, the rest of planner issues will be skipped" -
如果query存在limit节点（即查询语句中包含limit），则不会上报limit节点以下的Operator级别的告警。
子查询调优
子查询背景介绍
应用程序通过SQL语句来操作数据库时会使用大量的子查询，这种写法比直接对两个表做连接操作在结构上和思路上更清晰，尤其是在一些比较复杂的查询语句中，子查询有更完整、更独立的语义，会使SQL对业务逻辑的表达更清晰更容易理解，因此得到了广泛的应用。
openGauss根据子查询在SQL语句中的位置把子查询分成了子查询、子链接两种形式。
- 子查询SubQuery：对应于查询解析树中的范围表RangeTblEntry，更通俗一些指的是出现在FROM语句后面的独立的SELECT语句。
-
子链接SubLink：对应于查询解析树中的表达式，更通俗一些指的是出现在where/on子句、targetlist里面的语句。
综上，对于查询解析树而言，SubQuery的本质是范围表，而SubLink的本质是表达式。针对SubLink场景而言，由于SubLink可以出现在约束条件、表达式中，按照openGauss对SubLink的实现，SubLink可以分为以下几类：
- exist_sublink：对应EXIST、NOT EXIST语句
- any_sublink：对应op ALL(select…)语句，其中OP可以是IN、<、>、=操作符
- all_sublink：对应op ALL(select…)语句，其中OP可以是IN、<、>、=操作符
- rowcompare_sublink：对应record op (select …)语句
- expr_sublink：对应(SELECT with single targetlist item …)语句
- array_sublink：对应ARRAY(select…)语句
- cte_sublink：对应with query(…)语句
其中OLAP、HTAP场景中常用的sublink为exist_sublink、any_sublink，在openGauss的优化引擎中对其应用场景做了优化（子链接提升），由于SQL语句中子查询的使用的灵活性，会带来SQL子查询过于复杂造成性能问题。子查询从大类上来看，分为非相关子查询和相关子查询：
-
非相关子查询None-Correlated SubQuery
子查询的执行不依赖于外层父查询的任何属性值。这样子查询具有独立性，可独自求解，形成一个子查询计划先于外层的查询求解。
例如：
select t1.c1,t1.c2 from t1 where t1.c1 in ( select c2 from t2 where t2.c2 IN (2,3,4) ); QUERY PLAN ---------------------------------------------------------------- Hash Join Hash Cond: (t1.c1 = t2.c2) -> Seq Scan on t1 Filter: (c1 = ANY ('{2,3,4}'::integer[])) -> Hash -> HashAggregate Group By Key: t2.c2 -> Seq Scan on t2 Filter: (c2 = ANY ('{2,3,4}'::integer[])) (9 rows) -
相关子查询Correlated-SubQuery
子查询的执行依赖于外层父查询的一些属性值（如下列示例t2.c1 = t1.c1条件中的t1.c1）作为内层查询的一个AND-ed条件。这样的子查询不具备独立性，需要和外层查询按分组进行求解。
例如：
select t1.c1,t1.c2 from t1 where t1.c1 in ( select c2 from t2 where t2.c1 = t1.c1 AND t2.c2 in (2,3,4) ); QUERY PLAN ------------------------------------------------------------------------ Seq Scan on t1 Filter: (SubPlan 1) SubPlan 1 -> Seq Scan on t2 Filter: ((c1 = t1.c1) AND (c2 = ANY ('{2,3,4}'::integer[]))) (5 rows)
openGauss对SubLink的优化
针对SubLink的优化策略主要是让内层的子查询提升（pullup），能够和外表直接做关联查询，从而避免生成SubPlan+Broadcast內表的执行计划。判断子查询是否存在性能风险，可以通过explain查询语句查看Sublink的部分是否被转换成SubPlan的执行计划。
例如：
箭头右侧执行计划应替换成下面的执行计划：
QUERY PLAN
--------------------------------
Seq Scan on t1
Filter: (SubPlan 1)
SubPlan 1
-> Seq Scan on t2
Filter: (c1 = t1.c1)
(5 rows)
-
目前openGauss支持的Sublink-Release场景
-
IN-Sublink无相关条件
- 不能包含上一层查询的表中的列（可以包含更高层查询表中的列）。
- 不能包含易变函数。
箭头右侧执行计划应替换成下面的执行计划：
QUERY PLAN -------------------------------------- Hash Join Hash Cond: (t1.c1 = t2.c2) -> Seq Scan on t1 -> Hash -> HashAggregate Group By Key: t2.c2 -> Seq Scan on t2 Filter: (c1 = 1) (8 rows) -
Exist-Sublink包含相关条件
Where子句中必须包含上一层查询的表中的列，子查询的其它部分不能含有上层查询的表中的列。其它限制如下。
- 子查询必须有from子句。
- 子查询不能含有with子句。
- 子查询不能含有聚集函数。
- 子查询里不能包含集合操作、排序、limit、windowagg、having操作。
- 不能包含易变函数。
箭头右侧执行计划应替换成下面的执行计划：
QUERY PLAN
Hash Join
Hash Cond: (t1.c1 = t2.c1)
-> Seq Scan on t1
-> Hash
-> HashAggregate
Group By Key: t2.c1
-> Seq Scan on t2
(7 rows)
-
包含聚集函数的等值相关子查询的提升
子查询的where条件中必须含有来自上一层的列，而且此列必须和子查询本层涉及表中的列做相等判断，且这些条件必须用and连接。其它地方不能包含上层的列。其它限制条件如下。
- 子查询中where条件包含的表达式（列名）必须是表中的列。
-
子查询的Select关键字后，必须有且仅有一个输出列，此输出列必须是聚集函数（如max），并且聚集函数的参数（t2.c2）不能是来自外层表（t1）中的列。聚集函数不能是count。
例如，下列示例可以提升。
select * from t1 where c1 >( select max(t2.c1) from t2 where t2.c1=t1.c1 );下列示例不能提升，因为子查询没有聚集函数。
select * from t1 where c1 >( select t2.c1 from t2 where t2.c1=t1.c1 );下列示例不能提升，因为子查询有两个输出列。
select * from t1 where (c1,c2) >( select max(t2.c1),min(t2.c2) from t2 where t2.c1=t1.c1 ); -
子查询必须是from子句。
-
子查询中不能有groupby、having、集合操作。
-
子查询只能是inner join。
例如：下列示例不能提升。
select * from t1 where c1 >( select max(t2.c1) from t2 full join t3 on (t2.c2=t3.c2) where t2.c1=t1.c1 ); -
子查询的targetlist中不能包含返回set的函数。
-
子查询的where条件中必须含有来自上一层的列，而且此列必须和子查询层涉及表中的列做相等判断，且这些条件必须用and连接。其它地方不能包含上层的上层中的列。例如：下列示例中的最内层子链接可以提升。
select * from t3 where t3.c1=( select t1.c1 from t1 where c1 >( select max(t2.c1) from t2 where t2.c1=t1.c1 ));基于上面的示例，再加一个条件，则不能提升，因为最内侧子查询引用了上层中的列。示例如下：
select * from t3 where t3.c1=( select t1.c1 from t1 where c1 >( select max(t2.c1) from t2 where t2.c1=t1.c1 and t3.c1>t2.c2 ));
-
提升OR子句中的SubLink
当WHERE过滤条件中有OR连接的EXIST相关SubLink，
例如：
select a, c from t1 where t1.a = (select avg(a) from t3 where t1.b = t3.b) or exists (select * from t4 where t1.c = t4.c);将OR-ed连接的EXIST相关子查询OR字句的提升过程：
- 提取where条件中，or子句中的opExpr。为：t1.a = (select avg(a) from t3 where t1.b = t3.b)
-
这个op操作中包含subquery，判断是否可以提升，如果可以提升，重写subquery为：select avg(a)、 t3.b from t3 group by t3.b，生成not null条件t3.b is not null，并将这个opexpr用这个not null条件替换。此时SQL变为：
select a, c from t1 left join (select avg(a) avg, t3.b from t3 group by t3.b) as t3 on (t1.a = avg and t1.b = t3.b) where t3.b is not null or exists (select * from t4 where t1.c = t4.c); -
再次提取or子句中的exists sublink、exists (select * from t4 where t1.c = t4.c)，判断是否可以提升，如果可以提升，转换subquery为：select t4.c from t4 group by t4.c生成NotNull条件t4.c is not null提升查询，SQL变为：
select a, c from t1 left join (select avg(a) avg, t3.b from t3 group by t3.b) as t3 on (t1.a = avg and t1.b = t3.b) left join (select t4.c from t4 group by t4.c) where t3.b is not null or t4.c is not null;
-
-
目前openGauss不支持的Sublink-Release场景
除了以上场景之外都不支持Sublink提升，因此关联子查询会被计划成SubPlan+Broadcast的执行计划，当inner表的数据量较大时则会产生性能风险。
如果相关子查询中跟外层的两张表做join，那么无法提升该子查询，需要通过将父SQL创建成with子句，然后再跟子查询中的表做相关子查询查询。
例如：
select distinct t1.a, t2.a from t1 left join t2 on t1.a=t2.a and not exists (select a,b from test1 where test1.a=t1.a and test1.b=t2.a);改写为
with temp as ( select * from (select t1.a as a, t2.a as b from t1 left join t2 on t1.a=t2.a) ) select distinct a,b from temp where not exists (select a,b from test1 where temp.a=test1.a and temp.b=test1.b);-
出现在targetlist里的相关子查询无法提升（不含count）
例如：
explain (costs off) select (select c2 from t2 where t1.c1 = t2.c1) ssq, t1.c2 from t1 where t1.c2 > 10;执行计划为：
explain (costs off) select (select c2 from t2 where t1.c1 = t2.c1) ssq, t1.c2 from t1 where t1.c2 > 10; QUERY PLAN -------------------------------- Seq Scan on t1 Filter: (c2 > 10) SubPlan 1 -> Seq Scan on t2 Filter: (t1.c1 = c1) (5 rows)由于相关子查询出现在targetlist（查询返回列表）里，对于t1.c1=t2.c1不匹配的场景仍然需要输出值，因此使用left-outerjoin关联T1&T2确保t1.c1=t2.c1在不匹配时，子SSQ能够返回不匹配的补空值。
说明：
SSQ和CSSQ的解释如下：
- SSQ：ScalarSubQuery一般指返回1行1列scalar值的sublink，简称SSQ。
- CSSQ：Correlated-ScalarSubQuery和SSQ相同不过是指包含相关条件的SSQ。上述SQL语句可以改写为：
with ssq as ( select t2.c2 from t2 ) select ssq.c2, t1.c2 from t1 left join ssq on t1.c1 = ssq.c2 where t1.c2 > 10;改写后的执行计划为：
QUERY PLAN --------------------------------- Hash Right Join Hash Cond: (ssq.c2 = t1.c1) CTE ssq -> Seq Scan on t2 -> CTE Scan on ssq -> Hash -> Seq Scan on t1 Filter: (c2 > 10) (8 rows)可以看到出现在SSQ返回列表里的相关子查询SSQ，已经被提升成Right Join，从而避免当內表T2较大时出现SubPlan计划导致性能变差。
-
出现在targetlist里的相关子查询无法提升（带count）
例如：
select (select count(*) from t2 where t2.c1=t1.c1) cnt, t1.c1, t3.c1 from t1,t3 where t1.c1=t3.c1 order by cnt, t1.c1;执行计划为
QUERY PLAN -------------------------------------------- Sort Sort Key: ((SubPlan 1)), t1.c1 -> Hash Join Hash Cond: (t1.c1 = t3.c1) -> Seq Scan on t1 -> Hash -> Seq Scan on t3 SubPlan 1 -> Aggregate -> Seq Scan on t2 Filter: (c1 = t1.c1) (11 rows)由于相关子查询出现在targetlist（查询返回列表）里，对于t1.c1=t2.c1不匹配的场景仍然需要输出值，因此使用left-outerjoin关联T1&T2确保t1.c1=t2.c1在不匹配时子SSQ能够返回不匹配的补空值，但是这里带了count语句及时在t1.c1=t2.t1不匹配时需要输出0，因此可以使用一个case-when NULL then 0 else count(*)来代替。
上述SQL语句可以改写为：
with ssq as ( select count(*) cnt, c1 from t2 group by c1 ) select case when ssq.cnt is null then 0 else ssq.cnt end cnt, t1.c1, t3.c1 from t1 left join ssq on ssq.c1 = t1.c1,t3 where t1.c1 = t3.c1 order by ssq.cnt, t1.c1;改写后的执行计划为
QUERY PLAN ------------------------------------------- Sort Sort Key: ssq.cnt, t1.c1 CTE ssq -> HashAggregate Group By Key: t2.c1 -> Seq Scan on t2 -> Hash Join Hash Cond: (t1.c1 = t3.c1) -> Hash Left Join Hash Cond: (t1.c1 = ssq.c1) -> Seq Scan on t1 -> Hash -> CTE Scan on ssq -> Hash -> Seq Scan on t3 (15 rows) -
相关条件为不等值场景
例如：
复制代码
select t1.c1, t1.c2 from t1 where t1.c1 = (select agg() from t2.c2 > t1.c2);对于非等值相关条件的SubLink目前无法提升，从语义上可以通过做2次join（一次CorrelationKey，一次rownum自关联）达到提升改写的目的。
改写方案有两种。
-
子查询改写方式
复制代码
select t1.c1, t1.c2 from t1, ( select t1.rowid, agg() aggref from t1,t2 where t1.c2 > t2.c2 group by t1.rowid ) dt /* derived table */ where t1.rowid = dt.rowid AND t1.c1 = dt.aggref; -
CTE改写方式
复制代码
WITH dt as ( select t1.rowid, agg() aggref from t1,t2 where t1.c2 > t2.c2 group by t1.rowid ) select t1.c1, t1.c2 from t1, derived_table where t1.rowid = derived_table.rowid AND t1.c1 = derived_table.aggref;
-
须知：
- 对于AGG类型为count(*)时需要进行CASE-WHEN对没有match的场景补0处理，非COUNT(*)场景NULL处理。
- CTE改写方式如果有sharescan支持性能上能够更优。 -
更多优化示例
示例：修改select语句，将子查询修改为和主表的join，或者修改为可以提升的subquery，但是在修改前后需要保证语义的正确性。
explain (costs off) select * from t1 where t1.c1 in (select t2.c1 from t2 where t1.c1 = t2.c2);
QUERY PLAN
--------------------------------
Seq Scan on t1
Filter: (SubPlan 1)
SubPlan 1
-> Seq Scan on t2
Filter: (t1.c1 = c2)
(5 rows)
上面事例计划中存在一个subPlan，为了消除这个subPlan可以修改语句为：
explain (costs off) select * from t1 where exists (select t2.c1 from t2 where t1.c1 = t2.c2 and t1.c1 = t2.c1);
QUERY PLAN
------------------------------------------
Hash Join
Hash Cond: (t1.c1 = t2.c2)
-> Seq Scan on t1
-> Hash
-> HashAggregate
Group By Key: t2.c2, t2.c1
-> Seq Scan on t2
Filter: (c2 = c1)
(8 rows)
从计划可以看出，subPlan消除了，计划变成了两个表的hash join，这样会大大提高执行效率。
统计信息调优
统计信息调优介绍
openGauss是基于代价估算生成的最优执行计划。优化器需要根据analyze收集的统计信息行数估算和代价估算，因此统计信息对优化器行数估算和代价估算起着至关重要的作用。通过analyze收集全局统计信息，主要包括：pg_class表中的relpages和reltuples；pg_statistic表中的stadistinct、stanullfrac、stanumbersN、stavaluesN、histogram_bounds等。
实例分析1：未收集统计信息导致查询性能差
在很多场景下，由于查询中涉及到的表或列没有收集统计信息，会对查询性能有很大的影响。
表结构如下所示：
CREATE TABLE LINEITEM
(
L_ORDERKEY BIGINT NOT NULL
, L_PARTKEY BIGINT NOT NULL
, L_SUPPKEY BIGINT NOT NULL
, L_LINENUMBER BIGINT NOT NULL
, L_QUANTITY DECIMAL(15,2) NOT NULL
, L_EXTENDEDPRICE DECIMAL(15,2) NOT NULL
, L_DISCOUNT DECIMAL(15,2) NOT NULL
, L_TAX DECIMAL(15,2) NOT NULL
, L_RETURNFLAG CHAR(1) NOT NULL
, L_LINESTATUS CHAR(1) NOT NULL
, L_SHIPDATE DATE NOT NULL
, L_COMMITDATE DATE NOT NULL
, L_RECEIPTDATE DATE NOT NULL
, L_SHIPINSTRUCT CHAR(25) NOT NULL
, L_SHIPMODE CHAR(10) NOT NULL
, L_COMMENT VARCHAR(44) NOT NULL
) with (orientation = column, COMPRESSION = MIDDLE);
CREATE TABLE ORDERS
(
O_ORDERKEY BIGINT NOT NULL
, O_CUSTKEY BIGINT NOT NULL
, O_ORDERSTATUS CHAR(1) NOT NULL
, O_TOTALPRICE DECIMAL(15,2) NOT NULL
, O_ORDERDATE DATE NOT NULL
, O_ORDERPRIORITY CHAR(15) NOT NULL
, O_CLERK CHAR(15) NOT NULL
, O_SHIPPRIORITY BIGINT NOT NULL
, O_COMMENT VARCHAR(79) NOT NULL
)with (orientation = column, COMPRESSION = MIDDLE);
查询语句如下所示：
explain verbose select
count(*) as numwait
from
lineitem l1,
orders
where
o_orderkey = l1.l_orderkey
and o_orderstatus = 'F'
and l1.l_receiptdate > l1.l_commitdate
and not exists (
select
*
from
lineitem l3
where
l3.l_orderkey = l1.l_orderkey
and l3.l_suppkey <> l1.l_suppkey
and l3.l_receiptdate > l3.l_commitdate
)
order by
numwait desc;
当出现该问题时，可以通过如下方法确认查询中涉及到的表或列有没有做过analyze收集统计信息。
-
通过explain verbose执行query分析执行计划时会提示WARNING信息，如下所示：
WARNING:Statistics in some tables or columns(public.lineitem.l_receiptdate, public.lineitem.l_commitdate, public.lineitem.l_orderkey, public.lineitem.l_suppkey, public.orders.o_orderstatus, public.orders.o_orderkey) are not collected. HINT:Do analyze for them in order to generate optimized plan. -
可以通过在pg_log目录下的日志文件中查找以下信息来确认是当前执行的query是否由于没有收集统计信息导致查询性能变差。
2017-06-14 17:28:30.336 CST 140644024579856 20971684 [BACKEND] LOG:Statistics in some tables or columns(public.lineitem.l_receiptdate, public.lineitem.l_commitdate, public.lineitem.l_orderkey, public.linei tem.l_suppkey, public.orders.o_orderstatus, public.orders.o_orderkey) are not collected. 2017-06-14 17:28:30.336 CST 140644024579856 20971684 [BACKEND] HINT:Do analyze for them in order to generate optimized plan.
当通过以上方法查看到哪些表或列没有做analyze，可以通过对WARNING或日志中上报的表或列做analyze可以解决由于为收集统计信息导致查询变慢的问题。
算子级调优
算子级调优介绍
一个查询语句要经过多个算子步骤才会输出最终的结果。由于个别算子耗时过长导致整体查询性能下降的情况比较常见。这些算子是整个查询的瓶颈算子。通用的优化手段是EXPLAIN ANALYZE/PERFORMANCE命令查看执行过程的瓶颈算子，然后进行针对性优化。
如下面的执行过程信息中，Hashagg算子的执行时间占总时间的：(51016-13535)/ 56476 ≈66%，此处Hashagg算子就是这个查询的瓶颈算子，在进行性能优化时应当优先考虑此算子的优化。
算子级调优示例
示例1：基表扫描时，对于点查或者范围扫描等过滤大量数据的查询，如果使用SeqScan全表扫描会比较耗时，可以在条件列上建立索引选择IndexScan进行索引扫描提升扫描效率。
openGauss=# explain (analyze on, costs off) select * from store_sales where ss_sold_date_sk = 2450944;
id | operation | A-time | A-rows | Peak Memory | A-width
----+--------------------------------+---------------------+--------+--------------+---------
1 | -> Streaming (type: GATHER) | 3666.020 | 3360 | 195KB |
2 | -> Seq Scan on store_sales | [3594.611,3594.611] | 3360 | [34KB, 34KB] |
(2 rows)
Predicate Information (identified by plan id)
-----------------------------------------------
2 --Seq Scan on store_sales
Filter: (ss_sold_date_sk = 2450944)
Rows Removed by Filter: 4968936
openGauss=# create index idx on store_sales_row(ss_sold_date_sk);
CREATE INDEX
openGauss=# explain (analyze on, costs off) select * from store_sales_row where ss_sold_date_sk = 2450944;
id | operation | A-time | A-rows | Peak Memory | A-width
----+------------------------------------------------+-----------------+--------+--------------+----------
1 | -> Streaming (type: GATHER) | 81.524 | 3360 | 195KB |
2 | -> Index Scan using idx on store_sales_row | [13.352,13.352] | 3360 | [34KB, 34KB] |
(2 rows)
上述例子中，全表扫描返回3360条数据，过滤掉大量数据，在ss_sold_date_sk列上建立索引后，使用IndexScan扫描效率显著提高，从3.6秒提升到13毫秒。
示例2：如果从执行计划中看，两表join选择了NestLoop，而实际行数比较大时，NestLoop Join可能执行比较慢。如下的例子中NestLoop耗时181秒，如果设置参数enable_mergejoin=off关掉Merge Join，同时设置参数enable_nestloop=off关掉NestLoop，让优化器选择HashJoin，则Join耗时提升至200多毫秒。
示例3：通常情况下Agg选择HashAgg性能较好，如果大结果集选择了Sort+GroupAgg，则需要设置enable_sort=off，HashAgg耗时明显优于Sort+GroupAgg。
经验总结：SQL语句改写规则
根据数据库的SQL执行机制以及大量的实践，总结发现：通过一定的规则调整SQL语句，在保证结果正确的基础上，能够提高SQL执行效率。如果遵守这些规则，常常能够大幅度提升业务查询效率。
-
使用union all代替union。
union在合并两个集合时会执行去重操作，而union all则直接将两个结果集合并、不执行去重。执行去重会消耗大量的时间，因此，在一些实际应用场景中，如果通过业务逻辑已确认两个集合不存在重叠，可用union all替代union以便提升性能。
-
join列增加非空过滤条件。
若join列上的NULL值较多，则可以加上is not null过滤条件，以实现数据的提前过滤，提高join效率。
-
not in转not exists。
not in语句需要使用nestloop anti join来实现，而not exists则可以通过hash anti join来实现。在join列不存在null值的情况下，not exists和not in等价。因此在确保没有null值时，可以通过将not in转换为not exists，通过生成hash join来提升查询效率。
如下所示，如果t2.d2字段中没有null值（t2.d2字段在表定义中not null）查询可以修改为：
SELECT * FROM t1 WHERE NOT EXISTS (SELECT * FROM t2 WHERE t1.c1=t2.d2);产生的计划如下：
QUERY PLAN ------------------------------ Hash Anti Join Hash Cond: (t1.c1 = t2.d2) -> Seq Scan on t1 -> Hash -> Seq Scan on t2 (5 rows) -
选择hashagg。
查询中GROUP BY语句如果生成了groupagg+sort的plan性能会比较差，可以通过加大work_mem的方法生成hashagg的plan，因为不用排序而提高性能。
-
尝试将函数替换为case语句。
openGauss函数调用性能较低，如果出现过多的函数调用导致性能下降很多，可以根据情况把可下推函数的函数改成CASE表达式。
-
避免对索引使用函数或表达式运算。
对索引使用函数或表达式运算会停止使用索引转而执行全表扫描。
-
尽量避免在where子句中使用!=或<>操作符、null值判断、or连接、参数隐式转换。
-
对复杂SQL语句进行拆分。
对于过于复杂并且不易通过以上方法调整性能的SQL可以考虑拆分的方法，把SQL中某一部分拆分成独立的SQL并把执行结果存入临时表，拆分常见的场景包括但不限于：
- 作业中多个SQL有同样的子查询，并且子查询数据量较大。
- Plan cost计算不准，导致子查询hash bucket太小，比如实际数据1000W行，hash bucket只有1000。
- 函数（如substr、to_number）导致大数据量子查询选择度计算不准。
SQL调优关键参数调整
本节将介绍影响openGauss SQL调优性能的关键数据库主节点配置参数，配置方法参见配置运行参数。
表 1 数据库主节点配置参数
|
参数/参考值 |
描述 |
|---|---|
|
enable_nestloop=on |
控制查询优化器对嵌套循环连接（Nest Loop Join）类型的使用。当设置为“on”后，优化器优先使用Nest Loop Join；当设置为“off”后，优化器在存在其他方法时将优先选择其他方法。 说明： 如果只需要在当前数据库连接（即当前Session）中临时更改该参数值，则只需要在SQL语句中执行如下命令： 此参数默认设置为“on”，但实际调优中应根据情况选择是否关闭。一般情况下，在三种join方式（Nested Loop、Merge Join和Hash Join）里，Nested Loop性能较差，实际调优中可以选择关闭。 |
|
enable_bitmapscan=on |
控制查询优化器对位图扫描规划类型的使用。设置为“on”，表示使用；设置为“off”，表示不使用。 说明： 如果只需要在当前数据库连接（即当前Session）中临时更改该参数值，则只需要在SQL语句中执行命令如下命令： bitmapscan扫描方式适用于“where a > 1 and b > 1”且a列和b列都有索引这种查询条件，但有时其性能不如indexscan。因此，现场调优如发现查询性能较差且计划中有bitmapscan算子，可以关闭bitmapscan，看性能是否有提升。 |
|
enable_hashagg=on |
控制优化器对Hash聚集规划类型的使用。 |
|
enable_hashjoin=on |
控制优化器对Hash连接规划类型的使用。 |
|
enable_mergejoin=on |
控制优化器对融合连接规划类型的使用。 |
|
enable_indexscan=on |
控制优化器对索引扫描规划类型的使用。 |
|
enable_indexonlyscan=on |
控制优化器对仅索引扫描规划类型的使用。 |
|
enable_seqscan=on |
控制优化器对顺序扫描规划类型的使用。完全消除顺序扫描是不可能的，但是关闭这个变量会让优化器在存在其他方法的时候优先选择其他方法。 |
|
enable_sort=on |
控制优化器使用的排序步骤。该设置不可能完全消除明确的排序，但是关闭这个变量可以让优化器在存在其他方法的时候优先选择其他方法。 |
|
rewrite_rule |
控制优化器是否启用LAZY_AGG和MAGIC_SET重写规则。 |
|
sql_beta_feature |
控制优化器是否启用。SEL_SEMI_POISSON/SEL_EXPR_INSTR/PARAM_PATH_GEN/RAND_COST_OPT/PARAM_PATH_OPT/PAGE_EST_OPT/CANONICAL_PATHKEY/PARTITION_OPFUSION测试功能。 |
相关文章
