CN115062048A - 在分布式数据库上手动指定执行计划的方法 - Google Patents

Abstract

本发明公开了一种在分布式数据库上手动指定执行计划的方法，属一种分布式数据库的优化方法，在手动优化功能开启后，通过人工干预的方式影响当前SQL的执行计划，直至产生当前SQL的最优执行计划，并写入当前会话的缓存；将当前SQL的最优执行计划信息存储至分布式存储单元中，并将当前SQL的最优执行计划信息写入元数据表中。通过手动优化功能可在当前会话中对SQL的执行计划进行优化并生成最优执行计划，有效解决了SQL优化对系统运行的透明性，并且还解决了全局存储和本地缓存的同步和失效问题，有效提升了SQL编译的效率，使得某些不能自动生成最优执行计划的SQL，在应用无感知的情况下对SQL的执行计划进行调优。

Description

在分布式数据库上手动指定执行计划的方法

技术领域

本发明涉及一种分布式数据库的优化方法，更具体的说，本发明主要涉及一种在分布式数据库上手动指定执行计划的方法。

背景技术

目前主流的数据库优化器可以分为两种，分别为基于规则的优化器(Rule-BasedOptimizer，简称为RBO)与基于成本的优化器（Cost-Based Optimizer，简称为CBO）。基于规则的优化器(RBO)，是基于数据库内部预定的一些规则来对SQL进行优化，它对数据不敏感，只借助少量的信息来决定一个SQL语句的执行计划。基于成本的优化器（CBO），通过估算每个执行计划所需的成本，将每个执行计划所耗费的资源进行量化，最后选出成本最小的执行计划作为最优的执行计划。优化器在判断是否用这种方式时,主要参照的是表及索引的统计信息。目前主流数据库一般这两种优化器都会使用，先用RBO对SQL进行相应的变换，再依赖CBO，基于成本，生成最优的执行计划。而影响SQL执行计划的方式主要有两种技术方案，一是通过参数的调整来打开或关闭相关的优化功能；二是通过影响算子的成本来影响执行计划。

基于规则的优化和基于成本的优化都是尽最大可能的选取最优的执行计划，但是在生产环境中，还是会存在一部分SQL由于表结构创建不合理、统计信息不准确或者优化器本身的逻辑等等的原因导致没有命中最优的执行计划，从而导致SQL的执行效率比较低。对于这些SQL，如果数据库不能自动生成最优的执行计划，生产环境上只能通过手动影响执行计划的方式来临时解决该问题。而现有的两种技术方案在解决这类问题是也存在缺陷。

通过参数调整来开启或关闭某项优化功能使其生效的方式有两种，一种是在当前会话中立即生效，但是仅在当前会话中生效，不能影响到其他的会话，这也就导致了参数的修改不能在已经连接的其他会话里生效；另外一种参数修改后需要重新启动数据库服务才能生效，这种修改通常会影响到业务的运行，因此只能在系统运维的窗口里才能做这些修改。另外，参数的修改会影响到当前会话里将要执行的所有SQL，因此这样的修改通常会有副作用，不建议在生产环境上使用。

通过影响算子的成本来影响执行计划的方式有几种，如，可以通过伪造表的统计信息，但是伪造表上的统计信息会影响到和该表关联的所有SQL；另外，可以通过修改表结构或增加索引来影响执行计划，但是修改表结构会影响到正在运行的业务，需要专门的维护窗口，如果数据库本身不支持在线增加索引，增加索引的过程中也会影响运行中的业务，并且增加索引会对插入和更新的效率产生影响。数据库通常还提供另外一种方式：提示（Hint），通过在SQL里增加提示来影响优化器可以改变SQL的执行计划，但是通常通过增加提示的方式只能影响到当前的SQL，这在系统上线的前期用来优化帮助优化SQL是有帮助的，但是系统上线运行后，应用中的SQL已经固定，通过增加提示来改变执行计划的方式不再可行。

发明内容

本发明的目的之一在于针对上述不足，提供一种在分布式数据库上手动指定执行计划的方法，以期望解决现有技术中SQL编译由于生产环境中一部分SQL优化器不能直接命中其最优执行计划，需要人工干预，且不能进行分布式数据库系统的全局存储和本地缓存的同步、失效等技术问题。

为解决上述的技术问题，本发明采用以下技术方案。

本发明所提供的一种在分布式数据库上手动指定执行计划的方法，所述方法包括如下步骤。

步骤A、在手动优化功能开启后，通过人工干预的方式影响当前SQL的执行计划，直至产生当前SQL的最优执行计划，并写入当前会话的缓存；所述人工干预的方式包括在SQL中增加提示与伪造表上的统计信息。

步骤B、将当前SQL的最优执行计划信息存储至分布式存储单元中，并将当前SQL的最优执行计划信息写入元数据表中，且更改当前SQL在元数据表中对应执行计划的状态，然后记录当前SQL的最优执行计划信息在分布式存储单元中的位置。

步骤C、本节点与其它节点通信，使各个节点上的对应进程清空当前SQL在其自身节点中缓存的执行计划信息。

步骤D、向分布式数据库系统中的各个服务进程发出通知，更新当前SQL的执行计划，此前已缓存的执行计划失效。

作为优选，进一步的技术方案是：所述手动优化功能开启后，仅在当前会话中产生当前SQL的执行计划，直至获得当前SQL的最优执行计划。

更进一步的技术方案是：所述方法将当前SQL的最优执行计划信息序列化后再存储至所述分布式存储单元。

更进一步的技术方案是：所述方法还包括执行会话获取当前SQL的最优执行计划的步骤。

步骤H、在分布式数据库系统中正在执行的会话中，编译阶段首先判断当前SQL已缓存的执行计划是否失效；如判断结果为否，则返回执行计划，继续编译流程；如判断结果为是，执行步骤I。

步骤I、清空当前SQL在本节点当前的执行回话中已缓存的执行计划信息，然后判断本节点的共享缓存里是否有当前SQL的最优执行计划的缓存信息；如判断结果为是，执行步骤J；如判断结果为否，执行步骤K。

步骤J、进行反序列化后将当前SQL的最优执行计划信息写入当前执行会话的缓存中，再返回执行计划，继续编译流程。

步骤K、通过所述元数据表判断当前SQL是否在所述分布式存储单元中具有最优执行计划信息；如判断结果为是，执行步骤L；如判断结果为否，执行步骤M。

步骤L、将当前SQL的最优执行计划信息写入本节点的共享缓存内，然后进行反序列化后写入当前执行会话的缓存中，再则返回执行计划，继续编译流程。

步骤M、由优化器自动生成当前SQL的执行计划，并将当前SQL的执行计划信息写入本节点与当前执行会话的缓存中，然后将当前SQL的执行计划序列化后再写入所述分布式存储单元，并将当前SQL的执行计划信息写入元数据表中。

更进一步的技术方案是：所述方法中编译阶段判断当前SQL已缓存的执行计划是否失效时，如判断结果为否，则进一步判断当前执行会话的缓存中是否有当前SQL的最优执行计划的缓存信息；如判断结果为是，则返回执行计划，继续编译流程。如判断结果为否，则继续判断本节点的共享缓存里是否有当前SQL的最优执行计划的缓存信息。

更进一步的技术方案是：所述方法根据cacheKey清空会话或节点中缓存的SQL执行计划信息。

更进一步的技术方案是：所述方法在判断当前SQL已缓存的执行计划是否失效前，首先解析当前SQL，并校验SQL的有效性和执行权限，然后以此生成逻辑算子，并根据所述逻辑算子生成所述cacheKey。

与现有技术相比，本发明的有益效果之一是：通过手动优化功能可在当前会话中对SQL的执行计划进行优化并生成最优执行计划，然后将SQL的最优执行计划同步到整个分布式数据库系统的其他会话当中，有效解决了SQL优化对系统运行的透明性，并且还解决了全局存储和本地缓存的同步和失效问题，有效提升了SQL编译的效率，使得某些不能自动生成最优执行计划的SQL，在应用无感知的情况下对SQL的执行计划进行调优。

附图说明

图1为用于说明本发明一个实施例的方法流程图。

图2为用于说明本发明一个实施例中指定最优执行计划的同步流程图。

图3为用于说明本发明一个实施例中执行会话获取最优执行计划的流程图。

具体实施方式

基于背景技术中提到的缺陷，Oracle（甲骨文公司）提供了在单机数据库上的一种固定执行计划的解决方式，通过该方式，用户可以对SQL的执行计划通过Hint的方式进行修改，并将修改后的执行计划固定下来，并且正在运行的其他会话再执行该条SQL时可以应用新的执行计划。在此基础上，本发明提供了一种在分布式数据库上手动指定执行计划的一种不同的实现，可以做到在当前会话中对SQL的执行计划进行优化，并同步到整个分布式系统上的其他会话当中，有效解决了SQL优化对系统运行的透明性，并且本提案解决了全局存储和本地缓存的同步和失效问题，有效提升了SQL编译的效率。

本发明提供了一种在分布式数据库系统上手动指定执行计划的方法，该方法可以在优化器不能正确选择执行计划的时候通过手动的方式进行干预，手动生成指定的执行计划，并将该执行计划下发，可以影响正在运行的会话，从而达到对某些不能自动生成最优执行计划的SQL，在应用无感知的情况下对SQL的执行计划进行调优。

首先，需在分布式数据库中预设一个手动指定执行计划的开关，在开关开启时，系统仅会在当前会话产生执行计划，并不会立即将执行计划存储到分布式存储上，调优人员可以通过增加Hint或临时伪造统计信息等非DDL手段来对SQL的执行计划进行干预，从而产生最优的执行计划。一旦调优人员找到最优的执行计划，就可以通过指令，将当前最优执行计划存储到分布式存储上，同时将该执行计划的信息记入执行计划的元数据表上，将该SQL对应的执行计划的状态改为“Fixed”，并向整个分布式系统的服务进程发出通知，告知当前SQL的执行计划已经变掉，另外，会通过并行的算子在各个节点删除该SQL在共享缓存上对于的执行计划，具体的流程如图1所示。

结合图2所示，本实施例所述方法是按照如下的步骤执行的。

S1、在手动优化功能开启后，通过人工干预的方式影响当前SQL的执行计划，直至产生当前SQL的最优执行计划，并写入当前会话的缓存；前述的人工干预的方式包括在SQL中增加提示与伪造表上的统计信息。正如上述所提到的，在本步骤中，手动优化功能开启后，仅在当前会话中产生当前SQL的执行计划，直至获得当前SQL的最优执行计划。

S2、将当前SQL的最优执行计划信息存储至分布式存储单元中，并将当前SQL的最优执行计划信息写入元数据表中，且更改当前SQL在元数据表中对应执行计划的状态，然后记录当前SQL的最优执行计划信息在分布式存储单元中的位置；在本步骤中，最好将当前SQL的最优执行计划信息序列化后再写入所述分布式存储单元。

S3、在执行本实施方法的节点（以下简称本节点）与其它节点通信，使各个节点上的对应进程清空当前SQL在其自身节点中缓存的执行计划信息。

S4、向分布式数据库系统中的各个服务进程发出通知，更新当前SQL的执行计划，此前已缓存的执行计划失效。

其次，对于正在执行的会话，每条SQL在编译阶段都会先判断当前缓存的执行计划是否失效，如果没有失效，继续编译流程；如果已经失效，根据cacheKey清空本会话该SQL缓存的执行计划信息，然后查看本节点上是否存在该SQL对应的执行计划缓存，如果有，反序列化后存入本会话缓存，并返回给用户；如果没有，通过执行计划元数据表查看该SQL是否在分布式存储上有对应的信息，如果有，读取分布式存储上的执行计划信息，加载进本节点的共享缓存，然后反序列化后加载进本会话的缓存，返回给用户；如果没有，则继续编译流程。如果没有任何缓存的执行计划信息，优化器会生成执行计划，存入本会话缓存，然后将执行计划序列化后存入分布式存储，并将该执行计划的相关信息插入到执行计划的元数据表当中。

在本实施例中，通过手动优化功能可在当前会话中对SQL的执行计划进行优化并生成最优执行计划，然后将SQL的最优执行计划同步到整个分布式数据库系统的其他会话当中，有效解决了SQL优化对系统运行的透明性，并且还解决了全局存储和本地缓存的同步和失效问题，有效提升了SQL编译的效率，使得某些不能自动生成最优执行计划的SQL，在应用无感知的情况下对SQL的执行计划进行调优。

具体参考图3所示，通过人工干预的方式获得SQL的最优执行计划后，上述执行会话获取最优执行计划的步骤如下。

步骤1、在分布式数据库系统中正在执行的会话中，编译阶段首先判断当前SQL已缓存的执行计划是否失效。如判断结果为是，清空当前SQL在本节点当前的执行回话中已缓存的执行计划信息，执行步骤2；如判断结果为否，则返回执行计划，继续编译流程。

在本步骤中，优选的是，当上述判断结果为否时，则进一步判断当前执行会话的缓存中是否有当前SQL的最优执行计划的缓存信息；如判断结果为是，直接返回执行计划；如判断结果为否，则直接执行步骤2。

步骤2、判断本节点的共享缓存里是否有当前SQL的最优执行计划的缓存信息。如判断结果为是，执行步骤3.1；判断结果为否，执行步骤3.2。

步骤3.1、进行反序列化后将当前SQL的最优执行计划信息写入当前执行会话的缓存中，再返回执行计划，继续编译流程。

步骤3.2、通过所述元数据表判断当前SQL是否在所述分布式存储单元中具有最优执行计划信息。如判断结果为是，执行步骤4.1；如判断结果为否，执行步骤4.2。

步骤4.1、将当前SQL的最优执行计划信息写入本节点的共享缓存内，然后进行反序列化后写入当前执行会话的缓存中，再则返回执行计划，继续编译流程。

步骤4.2、由优化器自动生成当前SQL的执行计划，并将当前SQL的执行计划信息写入本节点与当前执行会话的缓存中，然后将当前SQL的执行计划序列化后再写入所述分布式存储单元，并将当前SQL的执行计划信息写入元数据表中。

正如上述所提到的，在图3所示执行会话获取最优执行计划的流程中，根据cacheKey清空会话或节点中缓存的SQL执行计划信息。并且在判断当前SQL已缓存的执行计划是否失效前，首先解析当前SQL，并校验SQL的有效性和执行权限，然后以此生成逻辑算子，并根据所述逻辑算子生成所述cacheKey。

通过上述的步骤即可实现SQL的最优执行计划的获取与编译，从而实现在分布式数据库上手动指定执行计划。

事实上，产生的SQL的最优执行计划信息会被写入当前会话的缓存，而本节点缓存里的执行计划信息来自于分布式存储，该节点上第一条执行的SQL会从分布式存储里将执行计划写入本节点的缓存，然后再写入本会话的缓存。本节点的其他会话执行同一条SQL，会直接从本节点的缓存里读取，然后写入本会话的缓存。执行计划的缓存分成三部分：当前执行会话的缓存（每个会话一份）、本节点的共享缓存（每个节点一份）和本集群的分布式缓存（每个集群一份）。

除上述以外，还需要说明的是在本说明书中所谈到的“一个实施例”、“另一个实施例”、“实施例”等，指的是结合该实施例描述的具体特征、结构或者特点包括在本申请概括性描述的至少一个实施例中。在说明书中多个地方出现同种表述不是一定指的是同一个实施例。进一步来说，结合任一实施例描述一个具体特征、结构或者特点时，所要主张的是结合其他实施例来实现这种特征、结构或者特点也落在本发明的范围内。

尽管这里参照本发明的多个解释性实施例对本发明进行了描述，但是，应该理解，本领域技术人员可以设计出很多其他的修改和实施方式，这些修改和实施方式将落在本申请公开的原则范围和精神之内。更具体地说，在本申请公开、附图和权利要求的范围内，可以对主题组合布局的组成部件和/或布局进行多种变型和改进。除了对组成部件和/或布局进行的变型和改进外，对于本领域技术人员来说，其他的用途也将是明显的。

Claims (7)

1.一种在分布式数据库上手动指定执行计划的方法，其特征在于所述的方法包括如下步骤：

在手动优化功能开启后，通过人工干预的方式影响当前SQL的执行计划，直至产生当前SQL的最优执行计划，并写入当前会话的缓存；所述人工干预的方式包括在SQL中增加提示与伪造表上的统计信息；

将当前SQL的最优执行计划信息存储至分布式存储单元中，并将当前SQL的最优执行计划信息写入元数据表中，且更改当前SQL在元数据表中对应执行计划的状态，然后记录当前SQL的最优执行计划信息在分布式存储单元中的位置；

本节点与其它节点通信，使各个节点上的对应进程清空当前SQL在其自身节点中缓存的执行计划信息；

向分布式数据库系统中的各个服务进程发出通知，更新当前SQL的执行计划，此前已缓存的执行计划失效。

2.根据权利要求1所述的在分布式数据库上手动指定执行计划的方法，其特征在于：所述手动优化功能开启后，仅在当前会话中产生当前SQL的执行计划，直至获得当前SQL的最优执行计划。

3.根据权利要求1所述的在分布式数据库上手动指定执行计划的方法，其特征在于：所述方法将当前SQL的最优执行计划信息序列化后再写入所述分布式存储单元。

4.根据权利要求3所述的在分布式数据库上手动指定执行计划的方法，其特征在于所述方法还包括如下步骤：

在分布式数据库系统中正在执行的会话中，编译阶段首先判断当前SQL已缓存的执行计划是否失效；

如判断结果为否，则返回执行计划，继续编译流程；

如判断结果为是，清空当前SQL在本节点当前的执行回话中已缓存的执行计划信息，然后判断本节点的共享缓存里是否有当前SQL的最优执行计划的缓存信息；

如判断结果为是，进行反序列化后将当前SQL的最优执行计划信息写入当前执行会话的缓存中，再返回执行计划，继续编译流程；

如判断结果为否，通过所述元数据表判断当前SQL是否在所述分布式存储单元中具有最优执行计划信息；

如判断结果为是，将当前SQL的最优执行计划信息写入本节点的共享缓存内，然后进行反序列化后写入当前执行会话的缓存中，再则返回执行计划，继续编译流程；

如判断结果为否，由优化器自动生成当前SQL的执行计划，并将当前SQL的执行计划信息写入本节点与当前执行会话的缓存中，然后将当前SQL的执行计划序列化后再写入所述分布式存储单元，并将当前SQL的执行计划信息写入元数据表中。

5.根据权利要求4所述的在分布式数据库上手动指定执行计划的方法，其特征在于：所述方法中编译阶段判断当前SQL已缓存的执行计划是否失效时，如判断结果为否，则进一步判断当前执行会话的缓存中是否有当前SQL的最优执行计划的缓存信息；

如判断结果为是，则返回执行计划，继续编译流程；

如判断结果为否，则继续判断本节点的共享缓存里是否有当前SQL的最优执行计划的缓存信息。

6.根据权利要求1或4所述的在分布式数据库上手动指定执行计划的方法，其特征在于：所述方法根据cacheKey清空会话或节点中缓存的SQL执行计划信息。

7.根据权利要求6所述的在分布式数据库上手动指定执行计划的方法，其特征在于：所述方法在判断当前SQL已缓存的执行计划是否失效前，首先解析当前SQL，并校验SQL的有效性和执行权限，然后以此生成逻辑算子，并根据所述逻辑算子生成所述cacheKey。

Images