CN114168620A - 执行计划的处理方法及装置 - Google Patents

Abstract

本公开提供了一种执行计划的处理方法及装置。该方法包括：对第一数据库语句进行等价改写，得到具有目标形态的第二数据库语句，所述目标形态关联第一规则；判断所述第二数据库语句对应的执行计划的形态是否符合所述第一规则；如果所述第二数据库语句对应的执行计划的形态符合所述第一规则，则根据所述第一数据库语句和所述第二数据库语句对应的执行计划的代价，确定目标执行计划。

Description

执行计划的处理方法及装置

技术领域

本公开涉及数据库技术领域，并且更具体地，涉及一种执行计划的处理方法及装置。

背景技术

数据库系统通常需要对数据库语句（如结构化查询语言（structured querylanguage，SQL）语句）进行等价改写，产生一个更优的数据库语句写法，从而产生一个更好的执行计划，降低数据库语句的执行耗时。

但是，将一个数据库语句改写成另外一种形式，并不一定总会产生更好的执行计划，需要优化器的代价系统比较改写前后的执行计划的代价，从而选择出代价更小的执行计划。

上述方式依赖于优化器的代价系统估算的准确性，在优化器的代价系统估算不准确的情况下，就会导致优化器选择了更差的执行计划，增加了数据库语句的执行耗时。

发明内容

本公开提供一种执行计划的处理方法及装置，有利于选择出更优的执行计划。

第一方面，提供一种执行计划的处理方法，包括：对第一数据库语句进行等价改写，得到具有目标形态的第二数据库语句，所述目标形态关联第一规则；判断所述第二数据库语句对应的执行计划的形态是否符合所述第一规则；如果所述第二数据库语句对应的执行计划的形态符合所述第一规则，则根据所述第一数据库语句和所述第二数据库语句对应的执行计划的代价，确定目标执行计划。

在一种可能的实现方式中，所述方法还包括：如果所述第二数据库语句对应的执行计划的形态不符合所述第一规则，则将所述第一数据库语句对应的执行计划确定为所述目标执行计划。

在一种可能的实现方式中，如果所述第二数据库语句对应的执行计划的形态符合所述第一规则，则所述目标执行计划为所述第一数据库语句和所述第二数据库语句对应的执行计划中代价较小的执行计划。

在一种可能的实现方式中，所述第一数据库语句和所述第二数据库语句为结构化查询语言SQL语句。

第二方面，提供一种执行计划的处理装置，包括：改写模块，用于对第一数据库语句进行等价改写，得到具有目标形态的第二数据库语句，所述目标形态关联第一规则；判断模块，用于判断所述第二数据库语句对应的执行计划的形态是否符合所述第一规则；确定模块，用于如果所述第二数据库语句对应的执行计划的形态符合所述第一规则，则根据所述第一数据库语句和所述第二数据库语句对应的执行计划的代价，确定目标执行计划。

在一种可能的实现方式中，所述确定模块还用于：如果所述第二数据库语句对应的执行计划的形态不符合所述第一规则，则将所述第一数据库语句对应的执行计划确定为所述目标执行计划。

在一种可能的实现方式中，如果所述第二数据库语句对应的执行计划的形态符合所述第一规则，则所述目标执行计划为所述第一数据库语句和所述第二数据库语句对应的执行计划中代价较小的执行计划。

在一种可能的实现方式中，所述第一数据库语句和所述第二数据库语句为结构化查询语言SQL语句。

第三方面，提供一种执行计划的处理装置，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如第一方面或第一方面中任一可能的实现方式中所述的方法。

第四方面，提供一种计算机可读存储介质，其上存储有可执行代码，当所述可执行代码被执行时，能够实现如第一方面或第一方面中任一可能的实现方式中所述的方法。

第五方面，提供一种计算机程序产品，包括可执行代码，当所述可执行代码被执行时，能够实现如第一方面或第一方面中任一可能的实现方式中所述的方法。

本公开实施例将改写后的第二数据库语句的形态与第一规则相关联，在进行目标执行计划的选择时，不仅考虑了改写前后执行计划的代价，还对改写后的执行计划的形态进行判断，只有符合第一规则的执行计划才能作为目标执行计划，从而可以避免优化器选择到不符合第一规则的执行计划，有利于获得更优的目标执行计划，降低数据库语句的执行耗时。

附图说明

图1是可应用于本公开实施例的数据库系统的结构示意图。

图2是本公开实施例提供的一种执行计划的处理方法的示意性流程图。

图3是本公开实施例提供的另一种执行计划的处理方法的示意性流程图。

图4是本公开实施例提供的一种执行计划的处理装置的示意性结构图。

图5是本公开实施例提供的另一种执行计划的处理装置的示意性结构图。

具体实施方式

下面将结合本公开实施例的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本公开一部分实施例，而不是全部的实施例。

图1是本公开实施例提供的一种数据库系统的示意图。该数据库系统100可以为一个服务器或由多个服务器组成的服务器集群。该数据库系统100可以包括数据库130和数据库管理系统（databasemanagementsystem，DBMS）120。本公开实施例的数据库可以为Oracle数据库或者OceanBase数据库。根据数据库支持的数据库语言的不同，数据库语句会有所不同。例如，不同的数据库可以使用不同标准的SQL语句。下文以SQL语句为例进行描述。

数据库可以指存储在数据存储器中的有组织的数据集合，即按照一定的数据模型组织、存储和使用的相关联的数据集合。数据存储器可以为固态硬盘、磁盘阵列或其他类别的非瞬态计算机可读介质。该数据库例如可以为关系型数据库，如该数据库可以包括一个或多个表数据。

关系型数据库是支持关系模型的数据库系统，一般采用二维表结构的存储方式，数据以行和/或列的方式进行存储。关系型数据库按照结构化的方法存储数据，每个数据表对各个字段定义好（也就是先定义好表的结构），再根据表的结构存入数据，这样做的好处就是由于数据的形式和内容在存入数据之前就已经定义好了，所以整个数据表就可以变得很清晰、一目了然，要读取和查询都十分方便，且可靠性和稳定性也比较高。为方便描述，下文将数据库中的数据集称为表。

根据存储原理的不同，关系型数据库可以为分布式关系型数据或者非分布式关系型数据库。

DBMS用于建立、使用和维护数据库，以及对数据库进行统一的管理和控制，以保证数据库的安全性和完整性。用户可以通过DBMS访问数据库中的数据。例如，用户可以通过DBMS修改或查询数据库中的数据。DBMS可以是关系型数据库管理系统（relationaldatabasemanagementsystem，RDBMS）。

在进行数据访问时，用户可以使用数据库语句访问数据库系统。数据库语句可以是SQL语句。通常，SQL是指专门用于管理关系型数据库中保存的数据的专用编程语言。SQL可以指代各种类型的数据相关语言，包括例如数据定义语言和数据操纵语言，其中SQL的范围可以包括数据插入，查询，更新和删除，模式创建和修改以及数据访问控制。此外，在一些示例中，SQL可以包括与各种语言元素相关的描述，包括子句（clause），表达式（expression），谓词（predicate），查询（query）和语句（statement）。其中，表达式可以被配置为产生包括数据列和/或行的标量值（scalar value）和/或表。谓词（Predicate，PRED）是计算结果为逻辑值（比如TRUE、FALSE、UNKNOWN）的逻辑表达式，可以用于描述对象之间的连接关系。比如，在SELECT查询语句中，在WHERE子句和HAVING子句中的过滤条件可以理解为指定谓词。举例来说，对于SQL语句{select*from A，B where A.a＝1 and A.a＜B.b}，A.a＝1 andA.a＜B.b指定了该查询语句的结果集中的行需要满足的条件，所以是该查询语句的谓词。

查询（query）是请求查看，访问和/或操纵存储在数据库中的数据。例如，数据库管理系统120可以从数据库客户端110接收SQL格式的查询（称为SQL查询）。通常，数据库管理系统通过通信接口，比如应用程序接口（application programming interface，API）或者以太网接口等网络接口接收客户端110的查询，从数据库访问相关数据并操纵相关数据以生成查询所对应的查询结果，并将查询结果通过上述通信接口返回到数据库客户端。

客户端110可以包括被配置成与数据库管理系统交互的任何类型的设备或应用程序。在一些示例中，客户端可以包括一个或多个应用服务器。

数据库管理系统120可以包括解析器、查询优化器、查询执行器和存储引擎。解析器用于执行对客户端提交的查询的语法、语义分析，将查询中的视图展开、划分为小的查询块。查询优化器为查询生成一组可能被使用的执行计划，估算出每个执行计划的代价，比较执行计划的代价，最终选择一个最优的执行计划。查询执行器依照查询的执行计划进行操作，以产生查询结果。存储引擎负责管理表的数据、索引的实际内容，同时也会管理运行时的Cache、Buffer、事务、Log等数据。例如存储引擎可以将执行引擎的执行结果通过物理输入/输出（input/output，I/O）写入数据存储器。

用户在对数据库进行数据操作（如数据查询操作）时，可以向数据库管理系统发送SQL语句。执行计划可以理解为数据库执行SQL语句的具体步骤，例如，是通过索引还是全表扫描的方式来访问数据库中的数据，或连接查询的实现方式和连接顺序等。

连接方式可以指把每一对行集连接起来的方式，即joinmethods。连接方式可以包括以下中的一种或多种：嵌套循环连接（NEST LOOP JOIN）、哈希连接（HASH JOIN）、合并连接（MERGE JOIN）和笛卡尔积（CARTESIAN PRODUCT）。每个连接方式都可以包括两个子部分，一个是驱动表（即外部表），另一个是被驱动表（即内部表）。

连接类型可以由连接的条件决定。连接类型可以包括内连接、外连接、半连接。外连接包括左外连接、右外连接和全外连接。上述每种连接方式（即joinmethods）都可以分为内连接、外连接和半连接。下面对半连接和内连接的连接方式进行介绍。

半连接

为了方便说明半连接的含义，这里使用“T1.C1 semi= T2.C1”来表示T1和T2之间做半连接。其中，T1是驱动表，T2是被驱动表，半连接条件为T1.C1 = T2.C1。“T1.C1 semi=T2.C1”的含义是只要在T2中找到一条记录满足T1.C1 = T2.C1，则停止搜索T2，并返回T1中满足条件T1.C1 = T2.C1的记录。也就是说，T2中满足半连接条件T1.C1 = T2.C1的记录即使有多条，T1中也只会返回第一条满足条件的记录。因此，半连接和普通的内连接不同，半连接实际上会去重。

内连接

为了方便说明内连接的含义，这里使用“T1.C1 innerjoin= T2.C1”来表示T1和T2之间做内连接。其中，T1是驱动表，T2是被驱动表，内连接条件为T1.C1 = T2.C1。“T1.C1innerjoin = T2.C1”的含义是，针对T1中的每一行，在T2中查找满足T1.C1 = T2.C1条件的数据，并返回T1和T2中满足T1.C1 = T2.C1的所有记录。内连接不会对重复的数据进行去重。

为了扩大执行计划的搜索空间，获得更优的执行计划。优化器需要对SQL语句进行等价改写，产生一个更优的SQL写法，从而生成一个更好的执行计划，降低SQL的执行耗时。

等价改写是将一种SQL语句改写为另一种SQL语句。改写前后的SQL语句的写法不同，但两者的执行结果一致。优化器在对SQL语句进行改写时，可以是对SQL语句中的表之间的连接方式和/或运算符等进行改写。

但是将一个SQL语句改写成另外一个SQL语句，并不一定总会产生更好的执行计划。执行计划的好坏还取决于实际的业务数据分布。有的时候改写会生成一个更好的执行计划，而有的时候会生成更差的执行计划。基于此，优化器可以引入代价验证的过程去判断一次代价改写是否生成了更好的SQL语句（或称为SQL形态）。这类需要进行代价验证的改写策略，通常被称之为代价改写策略，即基于代价的改写。

基于代价的改写（简称代价改写）可以指，数据库根据收集的表和索引的数据的统计信息综合来决定选取一个数据库认为最优（即代价最小）的执行计划（实际上并不一定最优）。统计信息用于反映对应数据库的关系表的数据分布情况。表内不同类型的数据的分布比例，或者不同类型的数据存储在哪些数据节点等。例如统计信息是指数据库中与表格、索引视图以及表格中的行或列等相关的可统计出的信息，例如可以是某一行中数据值的分布情况，数值分布是否均匀，最大值是多少，最小值是多少，表格包含的行数，某些数值的分布图等等。执行计划的代价可以包括中央处理单元（central processing unit，CPU）代价、IO代价和网络传输代价中的一种或多种。

举例说明，优化器可以对改写前后的执行计划的代价进行估计，比较改写前后的执行计划的代价大小。如果改写后的执行计划代价更低，即改写后的执行计划的代价小于改写前的执行计划的代价，则触发本次SQL语句的改写，优化器选用改写后的SQL语句对应的执行计划。如果改写后的执行计划的代价大于或等于改写前的执行计划的代价，则不触发本次SQL语句的改写，优化器选用改写前的SQL语句对应的执行计划。

可以理解的是，改写前的SQL语句对应的执行计划可以是优化器对改写前的SQL语句中的算子进行枚举得到的最优执行计划。改写后的SQL语句对应的执行计划可以是优化器对改写后的SQL语句中的算子进行枚举得到的最优执行计划。一个数据库语句可能包含多个算子，例如，连接（join）算子、group by算子、window function 算子、order by算子等。

上述方式采用对比改写前后的执行计划的代价是否降低来判断是否应该触发一次代价改写。这种方式非常依赖于优化器能够准确地估算执行计划的代价。但实际上，目前优化器的代价系统无法保证总是准确地估算出一个执行计划的代价。在统计信息不准确、数据存在严重倾斜、参与连接的表的数量较多等场景中，优化器很容易会错误地估算执行计划的行数和代价，这就容易导致优化器错误地触发了一次改写，从而产生一个更差的执行计划。

例如，如果优化器获取的统计信息不准确，实际上改写后的执行计划的代价比较高，但优化器会误认为改写后的执行计划的代价较低，从而触发了代价改写，使优化器选择了改写之后的执行计划，导致执行计划走偏，使用改写之后的执行计划反而会消耗更多的资源。

为了解决上述问题，本公开实施例考虑到数据库语句的改写都是有特定目标的，都是尝试去生成特定形态的执行计划，如果不进行语句改写，该特定形态的执行计划是不能生成的。换句话说，改写后的数据库语句相比于改写前的数据库语句，会有一些差异化的执行计划，只有通过语句改写，才有可能生成这些差异化的执行计划。

如果在经过语句改写后，优化器没有生成该特定形态的执行计划，而是生成了其他的执行计划，而其他非特定形态的执行计划并不是期望得到的执行计划，这就表明这次语句改写是没有必要的，数据库还不如使用改写之前的执行计划。考虑到特定的执行计划通常是符合一些规则要求的，且不同形态的数据库语句的改写是为了生成不同形态的执行计划，本公开实施例可以将数据库语句的形态与预设的规则相关联，通过判断改写后的执行计划是否符合预设的规则，来确定目标执行计划，从而可以避免优化器由于估算错误而选择了更差的执行计划。

下面结合图2，对本公开实施例提供的执行计划的处理方法进行介绍。图2所示的方法可应用于关系型数据。图2所示的方法可以由数据库中的优化器来执行。该数据库可以为OceanBase数据库或者Oracle数据库。下面对图2中的各个步骤进行详细说明。

在步骤S210、对第一数据库语句进行等价改写，得到具有目标形态的第二数据库语句。其中，目标形态关联第一规则。

第一数据库语句和第二数据库语句与数据库的类型有关，例如，第一数据库语句和第二数据库语句可以为SQL语句。

第一数据库语句可以是用户请求的语句，或者也可以是数据库对用户请求的数据库语句进行改写之后的语句。例如，数据库接收到用户发送的数据库语句后，可以对该数据库语句进行多次的改写，得到最终的数据库语句。在该情况下，第一数据库语句可以为最终的数据库语句之前的任一数据库语句。

第二数据库语句是第一数据库语句等价改写得到的，因此，第二数据库语句与第一数据库语句的计算结果一致。第一数据库语句与第二数据库语句是两种不同写法、但执行结果一致的数据库语句。

数据库语句的形态可以理解为数据库语句的写法。根据改写方式的不同，第二数据库语句具有不同的形态。例如，改写前后的SQL语句可以包括不同的连接方式和/或不同的表达式。数据库语句的改写方式可以有多种，本公开实施例对此不作进行限定。

作为一个示例，可以将半连接改写为内连接。也就是说，第一数据库语句中包括半连接的连接方式，优化器可以将第一数据库语句中的半连接改写为内连接，得到第二数据库语句。

以SQL语句为例进行举例说明，仍以上文中的“T1.C1 innerjoin= T2.C1”为例，改写前的SQL语句为：

SELECT T1.C1, T1.C2

FROM T1 SEMI

JOIN T2 ON T1.C1 = T2.C1;

改写后的SQL语句为：

SELECT T1.C1, T1.C2

FROM T1

INNER JOIN

(SELECT DISTINCT C1

FROM T2) V

ON T1.C1 = V.C1;

改写前的SQL语句中包括SEMIJOIN，也就是说，改写前的SQL语句包括半连接的连接方式。改写后的SQL语句包括INNER JOIN，也就是说，改写后的SQL语句包括内连接的连接方式。

作为另一个示例，可以将“OR”表达式展开进行改写。也就是说，第一数据库语句包括“OR”表达式，优化器可以将该“OR”表达式展开，得到第二数据库语句。

以查询T1表中的C1=1或C2=2的数据为例，改写前的SQL语句为：

SELECT T1.C1, T1.C2, T1.VAL FROM T1 WHERE C1 = 1 OR C2 = 2;

改写后的SQL语句为：

SELECT C1, C2, VAL FROM

(SELECT T1.C1, T1.C2, T1.VAL FROM T1 WHERE C1 = 1

UNION ALL

SELECT T1.C1, T1.C2, T1.VAL FROM T1 WHERE LNNVL(C1 = 1) AND C2 = 2

);

当然，数据库语句的改写方式还可以包括其他类型，例如，半连接改写外连接，半连接改写标量子查询，反连接改写外连接，反连接改写标量子查询，标量子查询改写为外连接等等，为了简洁，此处不再展开描述。

在步骤S220、判断第二数据库语句对应的执行计划的形态是否符合第一规则。

在步骤S230、如果第二数据库语句对应的执行计划的形态符合第一规则，则根据第一数据库语句和第二数据库语句对应的执行计划的代价，确定目标执行计划。

为方便描述，下文将第一数据库语句对应的执行计划称为第一执行计划，第二数据库语句对应的执行计划称为第二执行计划。

第二执行计划的形态可以理解为第二执行计划包含的算子类型和/或算子的属性信息。判断第二执行计划的形态是否满足第一规则，可以理解为判断第二执行计划是否包含特定的算子，和/或该特定的算子是否具有某种属性。

算子的类型可以包括表访问、连接、排序、聚合、分布式、集合和其他等类型。表访问的算子可以包括TABLE SCAN、TABLE GET等。连接算子可以包括NESTED-LOOP、BLK-NESTED-LOOP、MERGE、HASH等。排序算子可以包括SORT、TOP-N SORT等。聚合算子可以包括MERGE GROUP-BY、HASH GROUP-BY、WINDOW FUNCTION等。分布式算子可以包括EXCHANGE IN/OUT REMOTE/DISTRIBUTE等。集合算子可以包括UNION、EXCEPT、INTERSECT、MINUS等。其他算子可以包括LIMIT、MATERIAL、SUBPLAN、EXPRESSION、COUNT等。

算子的属性信息例如可以包括算子的ID信息、OPERATOR、NAME、EST.ROWS、COST中的一种或多种。算子的ID，执行树按照前序遍历的方式得到的编号，该编号从0开始进行编写，该ID是算子在执行计划中的唯一表示。OPERATOR表示操作算子的名称。EST.ROWS表示估算的该操作算子的输出行数。NAME表示对应表操作的表名（或索引名）。COST表示该操作算子的执行代价。

另外，执行计划中还包括操作算子的一些详细输出。这些输出也可以理解为操作算子的属性信息。例如，Output表示该算子的输出表达式列表。Filter表示该算子执行的过滤条件。Access表示表访问中存储层的投影列名。Partitions表示分区裁剪的信息。Sort_keys表示排序操作的排序键。Prefix_pos表示局部有序的偏移位置。Equal_conds表示连接操作中执行的等值连接条件。Other_conds表示连接操作中执行的非等值连接条件。

在将第一数据库语句改写成第二数据库语句后，优化器会生成与第二数据库语句对应的第二执行计划。进一步地，优化器可以判断第二数据库语句是否符合第一规则。如果第二数据库语句符合第一规则，则可以进一步对比改写前后执行计划的代价大小，并基于第一执行计划和第二执行计划的代价，确定目标执行计划。

目标执行计划可以是数据库最终的执行计划，或者也可以为多次改写过程中的中间一次的执行计划，本公开实施例对此并不限定。

本公开实施例在进行目标执行计划的选择时，不仅考虑了改写前后执行计划的代价，还对改写后的第二执行计划的形态进行判断，只有符合第一规则的第二执行计划才能作为目标执行计划，从而可以避免优化器选择到不符合第一规则的执行计划，有利于获得更优的目标执行计划，避免执行计划走偏。

在一些实施例中，如果第二执行计划的形态符合第一规则，则优化器可以比较第一执行计划和第二执行计划的代价大小，确定目标执行计划。优化器可以将代价较小的执行计划作为目标执行计划。也就是说，目标执行计划为第一执行计划和第二执行计划中代价较小的执行计划。

如果第一执行计划的代价较小，则优化器可以回退本次代价改写，保留原始的第一数据库语句，将第一执行计划作为目标执行计划。如果第二执行计划的代价较小，则优化器可以触发本次代价改写，保留改写后的第二数据库语句，将第二执行计划作为目标执行计划。

在另一些实施例中，如果第二执行计划的形态不符合第一规则，则优化器可回退本次代价改写，直接将第一执行计划确定为目标执行计划，从而可以避免优化器选择到不符合第一规则的执行计划。另外，如果第二执行计划不符合第一规则，优化器也不用生成第一执行计划，也不用对第一执行计划的代价和第二执行计划的代价进行比较，可以降低处理器资源的消耗。

下面结合图3，以SQL语句为例，对本公开实施例的执行计划的处理方法进行详细描述。

首先进行等价改写，将原始SQL语句进行改写，得到改写后的SQL语句。

计划形态检查，优化器可以先生成改写后的SQL语句对应的执行计划，简称为改写后的执行计划。优化器可以对该写后的执行计划的形态进行检查。如果改写后的执行计划形态通过检查，则优化器可以生成原始SQL语句对应的执行计划，简称为原始执行计划。进一步地，优化器可以对比改写前和改写后的执行计划的代价。如果改写后，执行计划的代价降低，则保留改写后的SQL语句；如果改写后，执行计划的代价增高，则保留原始SQL语句。

本公开实施例对第一规则不做具体限定。第一规则与第二数据库语句的形态有关，不同形态的第二数据库语句可以关联不同的规则。下文以SQL语句为例，结合具体情况对第一规则进行描述。

示例一、半连接改写内连接

以T1.C1=T2.C1查询为例，如果T1和T2之间使用半连接，由于T1为驱动表，T2为被驱动表，如果不进行改写，那么优化器就不能生成一个以T2为驱动表的带条件下推的NESTLOOP SEMI JOIN。由前文的描述可知，如果T1和T2之间使用半连接，则输出结果为T1表中满足“T1.C1=T2.C1”条件的数据。如果不进行改写，优化器是不会生成以T2为驱动表，T1为被驱动表的执行计划。当T2的数据量很少，T1的数据量很多，同时T1.C1=T2.C1具有很强的过滤性时，以T2为驱动表的NEST LOOP JOIN 会是非常理想的执行计划。因此，半连接改写内连接时，第一规则可以包括如下要求：

1、T2与T1的连接采用的是以T2为驱动表的NEST LOOP JOIN。

2、T1.C1=T2.C1被NEST LOOP JOIN转换为T1表上的下推谓词，并且该谓词被下压到索引上。

在将半连接改写为内连接时，改写后的执行计划只有符合上述条件，才有可能比改写前的执行计划具有更低的代价。也就是说，不符合上述条件的执行计划是不会具有更低的代价，这类执行计划不是通过改写期望产生的执行计划，因此，我们需要排除这类不符合规则要求的执行计划。

举例说明，如下列出的执行计划P1和P2，执行计划P1使用的是HASH JOIN，不是NEST LOOP JOIN，且执行计划P1并没有将谓词下压到T1表的索引上。因此，执行计划P1 不符合第一规则的要求，执行计划P1不能通过计划形态的检查。执行计划P2使用的是NESTLOOP JOIN，并且T1.C1=T2.C1被转换为T1表上的下推谓词，并且该谓词被下压到索引（如T1(IDX_C1)）上。因此，执行计划P2为符合第一规则的执行计划，执行计划P2可以通过计划形态的检查。

执行计划P1

========================================

|ID|OPERATOR |NAME|EST. ROWS|COST|

----------------------------------------

|0 |HASH JOIN | |990 |1702|

|1 | SUBPLAN SCAN |V |100 |847 |

|2 | HASH DISTINCT| |100 |845 |

|3 | TABLE SCAN |T2 |1000 |387 |

|4 | TABLE SCAN |T1 |1000 |387 |

========================================

执行计划P2

===============================================

|ID|OPERATOR |NAME |EST. ROWS|COST|

-----------------------------------------------

|0 |NESTED-LOOP JOIN| |990 |3132|

|1 | SUBPLAN SCAN |V |100 |847 |

|2 | HASH DISTINCT | |100 |845 |

|3 | TABLE SCAN |T2 |1000 |387 |

|4 | TABLE SCAN |T1(IDX_C1)|1 |22 |

===============================================

0 - output([T1.C1], [T1.C2]), filter(nil),

conds(nil), nl_params_([V.C1])

4 - output([T1.C1], [T1.C2]), filter(nil),

range_cond([T1.C1 = ])

示例二、OR展开

对于T1表中的C1=1 orC2=2的查询，如果不做OR展开，T1表的索引扫描只能选择一个索引，无法同时将C1=1和C2=2下压到索引上，用于确定扫描的边界。如果C1=1和C2=2的过滤性非常好，并且T1存在C1和C2列上的索引，那么OR展开是非常有效的改写策略。因此，OR展开关联的第一规则包括如下要求：

1、OR谓词拆分到每个UNION分支中的部分谓词都下压到索引上用于确定索引的扫描边界。

2、UNION的各个分支使用的是不同的索引。

在将OR展开时，改写后的执行计划只有符合上述条件，才有可能比改写前的执行计划具有更低的代价。也就是说，不符合上述条件的执行计划是不会具有更低的代价，这类执行计划不是通过改写期望产生的执行计划，因此，我们需要排除这类不符合规则要求的执行计划。

举例说明，对于如下的执行计划P3，由T1(IDX_C1)和T1(IDX_C2)可以看出，每个谓词都下压到索引上，且各个分支使用的是不同的索引；由range_cond([T1.C1 = 1])和range_cond([T1.C2 = 2])可以看出，不同分支中的谓词都下压到索引上用于确定索引的扫描边界。因此，执行计划P3符合上述第一规则，能够通过计划形态的检查。

对于执行计划P4，两个TABLESCAN访问的是T1表和T2表，并不是表的索引，也就是说，执行计划P4中的谓词没有下压到索引上，因此，执行计划P4不符合第一规则，不能通过计划形态的检查，只会导致T1被重复扫描多次，不会产生更低的代价。

执行计划P3

==========================================

|ID|OPERATOR |NAME |EST. ROWS|COST|

------------------------------------------

|0 |UNION ALL | |2 |183 |

|1 | TABLE SCAN|T1(IDX_C1)|1 |92 |

|2 | TABLE SCAN|T1(IDX_C2)|1 |92 |

==========================================

Outputs & filters:

-------------------------------------

0 - output([UNION([1])], [UNION([2])], [UNION([3])]), filter(nil)

1 - output([1], [T1.C2], [T1.VAL]), filter(nil),

access([T1.C2], [T1.VAL]), range_cond([T1.C1 = 1]), partitions(p0)

2 - output([T1.C1], [2], [T1.VAL]),

filter([lnnvl(cast(T1.C1 = 1, TINYINT(-1, 0)))]),

access([T1.C1], [T1.VAL]), range_cond([T1.C2 = 2]), partitions(p0)

执行计划P4

====================================

|ID|OPERATOR|NAME|EST. ROWS|COST|

------------------------------------

|0 |UNION ALL | |15 |818 |

|1 | TABLE SCAN|T1 |10 |408 |

|2 | TABLE SCAN|T1 |5 |410 |

====================================

Outputs & filters:

-------------------------------------

0 - output([UNION([1])], [UNION([2])], [UNION([3])]), filter(nil)

1 - output([1], [T1.C2], [T1.VAL]), filter([T1.C1 = 1]),

access([T1.C1], [T1.C2], [T1.VAL]), partitions(p0)

2 - output([T1.C1], [2], [T1.VAL]),

filter([T1.C2 = 2], [lnnvl(cast(T1.C1 = 1, TINYINT(-1, 0)))]),

access([T1.C1], [T1.C2], [T1.VAL]), partitions(p0)

上文结合图1至图3，详细描述了本公开的方法实施例，下面结合图4和图5，详细描述本公开的装置实施例。应理解，装置实施例的描述与方法实施例的描述相互对应，因此，未详细描述的部分可以参见前面方法实施例。

图4是本公开实施例提供的执行计划的处理装置的结构示意图。该装置400可应用于关系型数据库。该装置400可以为数据库中的优化器。该数据库可以为OceanBase数据库或者Oracle数据库。装置400包括改写模块410、判断模块420和确定模块430。下面分别对这些模块的功能进行介绍。

改写模块410，用于对第一数据库语句进行等价改写，得到具有目标形态的第二数据库语句，所述目标形态关联第一规则。

判断模块420，用于判断所述第二数据库语句对应的执行计划的形态是否符合所述第一规则。

确定模块430，用于如果所述第二数据库语句对应的执行计划的形态符合所述第一规则，则根据所述第一数据库语句和所述第二数据库语句对应的执行计划的代价，确定目标执行计划。

可选地，所述确定模块430还用于：如果所述第二数据库语句对应的执行计划的形态不符合所述第一规则，则将所述第一数据库语句对应的执行计划确定为所述目标执行计划。

可选地，如果所述第二数据库语句对应的执行计划的形态符合所述第一规则，则所述目标执行计划为所述第一数据库语句和所述第二数据库语句对应的执行计划中代价较小的执行计划。

可选地，所述第一数据库语句和所述第二数据库语句为SQL语句。

图5是本公开实施例提供的另一种执行计划的处理装置的结构示意图。图5所述的管理数据库装置500可以包括存储器510和处理器520，存储器510可以用于存储可执行代码。处理器520可以用于执行存储器510中存储的可执行代码，以实现前文描述的各个方法中的步骤。在一些实施例中，该装置500还可以包括网络接口530，处理器520与外部设备的数据交换可以通过该网络接口530实现。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本公开实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线（例如同轴电缆、光纤、数字用户线（digital subscriber line，DSL））或无线（例如红外、无线、微波等）方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够读取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储装置。所述可用介质可以是磁性介质，（例如，软盘、硬盘、磁带）、光介质（例如，数字通用光盘（digital video disc，DVD））或者半导体介质（例如，固态硬盘（solid state disk，SSD））等。

以上所述，仅为本公开的具体实施方式，但本公开的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应以所述权利要求的保护范围为准。

Claims (9)

1.一种执行计划的处理方法，包括：

对第一数据库语句进行等价改写，得到具有目标形态的第二数据库语句，所述目标形态关联第一规则；

判断所述第二数据库语句对应的执行计划的形态是否符合所述第一规则；

如果所述第二数据库语句对应的执行计划的形态符合所述第一规则，则根据所述第一数据库语句和所述第二数据库语句对应的执行计划的代价，确定目标执行计划。

2.根据权利要求1所述的方法，所述方法还包括：

如果所述第二数据库语句对应的执行计划的形态不符合所述第一规则，则将所述第一数据库语句对应的执行计划确定为所述目标执行计划。

3.根据权利要求1所述的方法，如果所述第二数据库语句对应的执行计划的形态符合所述第一规则，则所述目标执行计划为所述第一数据库语句和所述第二数据库语句对应的执行计划中代价较小的执行计划。

4.根据权利要求1所述的方法，所述第一数据库语句和所述第二数据库语句为结构化查询语言SQL语句。

5.一种执行计划的处理装置，包括：

改写模块，用于对第一数据库语句进行等价改写，得到具有目标形态的第二数据库语句，所述目标形态关联第一规则；

判断模块，用于判断所述第二数据库语句对应的执行计划的形态是否符合所述第一规则；

确定模块，用于如果所述第二数据库语句对应的执行计划的形态符合所述第一规则，则根据所述第一数据库语句和所述第二数据库语句对应的执行计划的代价，确定目标执行计划。

6.根据权利要求5所述的装置，所述确定模块还用于：

如果所述第二数据库语句对应的执行计划的形态不符合所述第一规则，则将所述第一数据库语句对应的执行计划确定为所述目标执行计划。

7.根据权利要求5所述的装置，如果所述第二数据库语句对应的执行计划的形态符合所述第一规则，则所述目标执行计划为所述第一数据库语句和所述第二数据库语句对应的执行计划中代价较小的执行计划。

8.根据权利要求5所述的装置，所述第一数据库语句和所述第二数据库语句为结构化查询语言SQL语句。

9.一种执行计划的处理装置，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器被配置为执行所述可执行代码，以实现权利要求1-4中任一项所述的方法。

Images