CN113312371A - 执行计划的处理方法、设备及系统 - Google Patents

Abstract

本申请公开了一种执行计划的处理方法、设备及系统，属于数据库领域。所述方法包括：执行结构化查询语言SQL语句的第一执行计划；在所述SQL语句的第一执行计划的性能劣化时，获取所述SQL语句的第二执行计划；执行所述第二执行计划来替换对所述第一执行计划的执行。本申请用于减少劣化的执行计划对数据库的影响，本申请实施例用于数据库中执行计划的执行。

Description

执行计划的处理方法、设备及系统

本申请要求于2020年2月27日提交的申请号为202010124587.2、发明名称为“执行计划性能裂变自恢复方法”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。

技术领域

本申请涉及数据库领域，特别涉及一种执行计划的处理方法、设备及系统。

背景技术

在数据库中，用户采用结构化查询语言(Structured Query Language)SQL语句进行数据的查询。查询引擎可以为一条SQL语句生成一个执行计划，并在一段时间内基于该执行计划进行数据的处理。其中，执行计划(也称SQL执行计划)用于指示执行的动作，以及执行动作的先后顺序等。

但是，由于每个执行计划会在一段时间(如几周)内持续使用，若该执行计划本身性能较差，会在该段时间内影响数据库的性能。

发明内容

本申请实施例提供了一种执行计划的处理方法、设备及系统。所述技术方案如下：

第一方面，提供一种执行计划的处理方法，该方法可以由数据库系统执行，该方法包括：

执行结构化查询语言SQL语句的第一执行计划；在该SQL语句的第一执行计划的性能劣化时，获取该SQL语句的第二执行计划；执行该第二执行计划来替换对该第一执行计划的执行。

本申请实施例中，在分析到第一执行计划的性能劣化后，会采用第二执行计划替换第一执行计划，以避免数据库使用性能劣化的第一执行计划，减少性能劣化的执行计划对数据库的影响，从而保证数据库的性能。

可选地，该第二执行计划与该第一执行计划不同。进一步可选地，该第二执行计划的性能优于该第一执行计划的性能，可以有效保证数据库的性能。

可选地，获取SQL语句的第二执行计划的实现方式有多种，本申请实施例以以下两种获取方式为例进行说明：

第一种获取方式：获取该SQL语句的历史执行计划；当该历史执行计划的性能优于该第一执行计划的性能时，将该历史执行计划作为该第二执行计划。

可选地，可以在SQL语句的其他执行计划(该其他执行计划是在第一执行计划之前生成的执行计划)中确定历史执行计划，以判定该历史执行计划是否可以作为第二执行计划。示例的，该历史执行计划可以是SQL语句的其他执行计划中性能最优的执行计划、历史使用时间最长的执行计划或符合其他设定条件的执行计划。

采用该第一种获取方式，由于历史执行计划已经预先生成，因此可以快速获取优于第一执行计划的性能的历史执行计划作为第二执行计划，能够实现执行计划的快速优化，提高优化效率。

第二种获取方式：生成该SQL语句的第二执行计划。

可选地，生成该SQL语句的第二执行计划所占用的计算资源大于生成该SQL语句的第一执行计划所占用的计算资源，和/或，生成该SQL语句的第二执行计划的时长大于生成该SQL语句的第一执行计划的时长。

由于在生成时间和/或占用的计算资源上减少了对生成执行计划过程的限制，可以保证最终确定的第二执行计划的性能优于第一执行计划的性能。

可选地，本申请实施例提供的数据库系统还支持告警功能。相应的，该执行计划的处理方法还包括：在该SQL语句的第一执行计划的性能劣化时，发送告警指示信息。可选地，该告警指示信息可以包括SQL语句，即产生性能劣化的SQL语句；该告警指示信息还可以包括指示进行执行计划的干预的任务。用户可以基于该告警指示信息知晓当前出现性能劣化的SQL语句，并判定是否进行执行计划的干预。

本申请实施例中，通过用户界面将告警指示信息呈现给用户，由用户来控制是否进行执行计划的优化，可以避免后台自动进行执行计划的优化影响用户的操作或影响正在执行的用户业务，提高执行计划干预的时间上的灵活性，提高用户体验。

获取SQL语句的第二执行计划的过程可以有多种触发方式，例如，在接收到执行计划优化指令后，获取该SQL语句的第二执行计划。该执行计划优化指令可以是用户通过应用程序触发，也可以由指定设备触发。该执行计划优化指令用于指示对劣化的执行计划进行干预。

可选地，该方法还包括：在新版本的执行计划的性能优于该第二执行计划的性能时，执行该新版本的执行计划来替换对该第二执行计划的执行。

本申请实施例在新版本的执行计划的性能优于第二执行计划的性能时，数据库系统才执行新版本的执行计划来替换对第二执行计划的执行，以避免数据库采用性能劣化的新版本的执行计划，减少性能劣化的执行计划对数据库的影响，从而保证数据库的性能。并且，由于该新版本的执行计划的性能优于第二执行计划的性能，可以有效保证数据库的性能，避免数据库版本回退，减少业务中断时长。

运行指标用于反映对应的执行计划的运行效果，也可以反映对应的SQL语句的性能。通过第一执行计划的运行指标可以确定第一执行计划的性能。则当该第一执行计划的运行指标出现异常时，确定该SQL语句的第一执行计划的性能劣化。示例的，第一执行计划的运行指标包括以下的一种或多种：SQL语句的IO指标、时延(delay)、错误(error)信息、执行次数和处理时长。

可选地，数据库系统分析第一执行计划的运行指标是否异常的过程可以包括：对于第一执行计划的运行指标中的每个运行指标，将该运行指标对应的运行指标数据组与对应的历史运行指标数据组对比，来确定每个运行指标是否异常；基于每个运行指标的异常判定结果，确定第一执行计划的运行指标(即第一执行计划整体的运行指标)是否异常。

可选地，对于该第一执行计划的运行指标中的每个运行指标，确定该运行指标是否异常的可实现方式可以包括：

第一种可实现方式，对于该第一执行计划的运行指标中的每个运行指标，当该运行指标对应的运行指标数据组指示的性能低于该运行指标对应的该SQL语句的历史运行指标数据组指示的性能，确定该运行指标出现异常。

其中，对于该第一执行计划的运行指标中的每个运行指标，确定该运行指标对应的运行指标数据组指示的性能是否低于该运行指标对应的该SQL语句的历史运行指标数据组指示的性能的方式可以有以下两种：

第一种方式，数据库系统基于指定比较规则将对应的运行指标数据组与对应的历史运行指标数据组进行比较，以检测运行指标数据组指示的性能是否低于对应的历史运行指标数据组指示的性能。

例如，数据库系统维护有专家经验库，该专家经验库记载有基于专家经验确定的至少一个指定比较规则，数据库系统基于该指定比较规则，进行运行指标对应的运行指标数据组与对应的历史运行指标数据组的比较。

又例如，数据库系统通过将运行指标数据组的性能曲线与运行指标的性能基线进行比较，以检测运行指标数据组指示的性能是否低于历史运行指标数据组指示的性能。

当该运行指标对应的运行指标数据组的性能曲线与该运行指标的性能基线不匹配时，确定该运行指标对应的运行指标数据组指示的性能低于该历史运行指标数据组指示的性能，该运行指标的性能基线基于该历史运行指标数据组确定。

可选地，在使用该运行指标的性能基线之前，数据库系统还可以基于第二人工智能模型以及该历史运行指标数据组，生成该运行指标的性能基线。

运行指标的性能基线由人工智能模型生成，在保证性能基线的准确性的基础上，还可以提高性能基线的获取效率。

第二种可实现方式，数据库系统通过AI模型来识别该第一运行指标是否出现异常。该过程如下：

对于该第一执行计划的运行指标中的每个运行指标，将该运行指标对应的运行指标数据组输入第一人工智能模型，当该第一人工智能模型输出指示该运行指标异常的指示信息，确定该运行指标出现异常。

前述两种可实现方式可以根据实际情况进行结合，例如，先执行第一种可实现方式提供的方法，以进行异常的运行指标数据组的粗筛选，该粗筛选过程存在一定的误差，可能出现把非异常的运行指标数据组确定为异常的运行指标数据组的情况；再对粗筛选结果为异常的运行指标数据组执行第二种可实现方式提供的方法，以进行异常的运行指标数据组的精筛选。

对于第一执行计划的运行指标中的每个运行指标，当该运行指标数据组指示的性能低于SQL语句的历史运行指标数据组指示的性能(即通过粗筛选确定该运行指标数据组异常)，将运行指标数据组输入第一人工智能模型，当第一人工智能模型输出指示运行指标数据组异常的指示信息，确定第一执行计划的运行指标数据组出现异常(即通过精筛选确定该运行指标数据组异常)，相对于前述第二种可实现方式，可以提高确定运行指标数据组异常的精确度。当该运行指标数据组指示的性能不低于SQL语句的历史运行指标数据组指示的性能(即通过粗筛选确定该运行指标数据组正常)，无需将运行指标数据组输入第一人工智能模型，相对于前述第二种可实现方式，可以减少第一人工智能模型的运算代价。

可选地，数据库系统基于每个运行指标的异常判定结果，确定第一执行计划的运行指标是否出现异常的方式可以有多种，本申请实施例以以下几种可选方式为例进行说明：

在第一种可选方式中，当第一执行计划的至少一个运行指标出现异常，确定第一执行计划的运行指标出现异常；当第一执行计划的所有运行指标均未出现异常，确定第一执行计划的运行指标未出现异常。

在第二种可选方式中，基于每个运行指标的异常判定结果，确定第一执行计划的运行指标分数，当该运行指标分数大于指定分数阈值，确定该第一执行计划的运行指标出现异常；当该运行指标分数不大于指定分数阈值，确定该第一执行计划的运行指标未出现异常。也即是该运行指标分数越高，出现异常的概率越高。

在一种可能实现方式中，在该获取该SQL语句的第二执行计划之后，该执行计划的处理方法还包括：将该第二执行计划转化为与管理节点匹配的第二执行计划。以保证管理节点能够快速解析转化后的第二执行计划，从而减少管理节点产生的解析时延，提高管理节点对第二执行计划的加载和使用效率。

可选地，该将该第二执行计划转化为与管理节点匹配的第二执行计划的过程，包括：

查询指定的管理节点与执行计划格式的对应关系，得到该管理节点对应的执行计划格式；将该第二执行计划转化为符合该执行计划格式的第二执行计划。

可选地，该第二执行计划携带著录提示标签，该著录提示标签用于标识对应的执行计划为经过干预的执行计划。如此可以便于数据库系统区分哪些执行计划是经过干预的执行计划。

可选地，该生成该SQL语句的第二执行计划的过程可以包括：基于管理节点所在数据库的优化规则信息和/或优化成本信息，生成多个备选执行计划；遍历该多个备选执行计划，得到该第二执行计划。

可选地，该执行计划的处理方法还可以包括：接收规则设置指令，该规则设置指令包括设置的规则。可选地，数据库系统中的规则可以包括以下至少一种：SQL性能对比规则、著录提示标签设置规则、告警规则和路由规则。

第二方面，提供一种执行计划的处理方法，该方法可以由数据库系统执行，该方法包括：

执行结构化查询语言SQL语句的第一执行计划；获取该SQL语句的新版本的第二执行计划；在该第二执行计划的性能优于该第一执行计划的性能时，执行该第二执行计划来替换对该第一执行计划的执行。

本申请实施例在新版本的第二执行计划的性能优于第一执行计划的性能时，数据库系统才执行第二执行计划来替换对第一执行计划的执行，以避免数据库采用性能劣化的新版本的执行计划，减少性能劣化的执行计划对数据库的影响，从而保证数据库的性能。并且，由于该第二执行计划的性能优于第一执行计划的性能，可以有效保证数据库的性能，避免数据库版本回退，减少业务中断时长。

在一种可能实现方式中，在获取该SQL语句的第二执行计划之后，例如在确定该第二执行计划的性能优于该第一执行计划的性能后，该方法还包括：将该第二执行计划转化为与管理节点匹配的第二执行计划。以保证管理节点能够快速解析转化后的第二执行计划，从而减少管理节点产生的解析时延，提高管理节点对第二执行计划的加载和使用效率。

可选地，该将该第二执行计划转化为与管理节点匹配的第二执行计划的过程，包括：查询指定的管理节点与执行计划格式的对应关系，得到该管理节点对应的执行计划格式；将该第二执行计划转化为符合该执行计划格式的第二执行计划。

可选地，获取该SQL语句的新版本的第二执行计划包括：生成该SQL语句的第二执行计划，该生成该SQL语句的第二执行计划的过程可以包括：基于管理节点所在数据库的优化规则信息和/或优化成本信息，生成多个备选执行计划；遍历该多个备选执行计划，得到该第二执行计划。

第三方面，本申请提供一种数据库系统，该数据库系统可以包括至少一个模块，该至少一个模块可以用于实现上述第一方面或者第一方面的各种可能实现提供的该执行计划的处理方法。

第四方面，本申请提供一种数据库系统，该数据库系统可以包括至少一个模块，该至少一个模块可以用于实现上述第一方面或者第一方面的各种可能实现提供的该执行计划处理方法。

第五方面，本申请提供一种计算机设备，该计算机设备包括处理器和存储器。该存储器存储计算机指令；该处理器执行该存储器存储的计算机指令，使得该计算机设备执行上述第一方面或者第一方面的各种可能实现提供的方法，使得该计算机设备部署上述第三方面或者第三方面的各种可能实现提供的该数据库系统。

第六方面，本申请提供一种计算机设备，该计算机设备包括处理器和存储器。该存储器存储计算机指令；该处理器执行该存储器存储的计算机指令，使得该计算机设备执行上述第二方面或者第二方面的各种可能实现提供的方法，使得该计算机设备部署上述第四方面或者第四方面的各种可能实现提供的该数据库系统。

第七方面，本申请提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机指令，该计算机指令指示该计算机设备执行上述第一方面或者第一方面的各种可能实现提供的方法，或者该计算机指令指示该计算机设备部署上述第三方面或者第三方面的各种可能实现提供的数据库系统。

第八方面，本申请提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机指令，该计算机指令指示该计算机设备执行上述第二方面或者第二方面的各种可能实现提供的方法，或者该计算机指令指示该计算机设备部署上述第四方面或者第四方面的各种可能实现提供的数据库系统。

第九方面，本申请提供一种计算机程序产品，该计算机程序产品包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器可以从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述第一方面或者第一方面的各种可能实现提供的方法，使得该计算机设备部署上述第三方面或者第三方面的各种可能实现提供的数据库系统。

第十方面，本申请提供一种计算机程序产品，该计算机程序产品包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器可以从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述第二方面或者第二方面的各种可能实现提供的方法，使得该计算机设备部署上述第四方面或者第四方面的各种可能实现提供的数据库系统。

第十一方面，提供一种芯片，该芯片可以包括可编程逻辑电路和/或程序指令，当该芯片运行时用于实现如第一方面任一该的执行计划的处理方法。或者，当该芯片运行时用于实现如第二方面任一该的执行计划的处理方法。

本申请实施例提供的技术方案带来的有益效果是：

本申请实施例在分析到第一执行计划的性能劣化后，会采用第二执行计划替换第一执行计划，以避免数据库使用性能劣化的第一执行计划，减少性能劣化的执行计划对数据库的影响，从而保证数据库的性能。可选地，该第二执行计划的性能优于第一执行计划的性能，从而有效保证数据库的性能。

本申请实施例在新版本的第二执行计划的性能优于第一执行计划的性能时，数据库系统才执行第二执行计划来替换对第一执行计划的执行，以避免数据库采用性能劣化的新版本的执行计划，减少性能劣化的执行计划对数据库的影响，从而保证数据库的性能。并且，由于该第二执行计划的性能优于第一执行计划的性能，可以有效保证数据库的性能，避免数据库版本回退，减少业务中断时长。

附图说明

图1是本申请实施例提供的执行计划的处理方法所涉及数据库系统的一种应用环境的示意图；

图2是本申请实施例提供的一种执行计划的处理方法的流程示意图；

图3是本申请实施例提供一示意性的数据库系统中数据流向示意图；

图4是本申请实施例提供的一种第一运行指标的性能基线的示意图；

图5是本申请实施例提供的一种第一运行指标数据组的性能曲线与第一运行指标的性能基线的比较场景示意图；

图6是本申请实施例提供的一种第一运行指标数据组的数值点与第一运行指标的性能基线的比较场景示意图；

图7是本申请实施例提供的一种示意性的用户界面的示意图；

图8是本申请实施例提供的一种数据库系统的结构示意图；

图9是本申请实施例提供的一种执行计划的处理方法的流程示意图；

图10是本申请实施例提供的一种数据库系统的框图；

图11是本申请实施例提供的另一种数据库系统的框图；

图12是本申请实施例提供的又一种数据库系统的框图；

图13是本申请实施例提供的再一种数据库系统的框图；

图14是本申请另一实施例提供的一种数据库系统的框图；

图15是本申请实施例提供的一种计算机设备的框图。

具体实施方式

为使本申请的目的、技术方案和原理更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

图1是本申请实施例提供的执行计划的处理方法所涉及数据库系统(DatabaseSystem，DBS)10的一种应用环境的示意图。该数据库系统10可以为一个服务器或者由多个服务器组成的服务器集群。该数据库系统包括数据库管理系统(Database ManagementSystem，DBMS)和至少一个数据库(Database，DB)(图1未示出)。在该数据库系统中，应用程序可以通过数据库管理系统对数据库进行透明操作，数据库中的数据由数据库管理系统进行管理。

可选地，前述数据库可以为关系型数据库(relational database)，关系型数据库是指采用了关系模型来组织数据的数据库。其以行和列的形式存储数据。每个关系模型可以称为一个关系表。根据存储原理的不同，关系型数据库可以分为分布式关系型数据库和非分布式关系型数据库。

其中，数据库系统10包括：管理节点(也称查询引擎、SQL引擎、数据库引擎或协调数据节点，coordinator)101、多个数据节点102和优化节点103。数据库系统10可以包括一个或多个管理节点101，每个管理节点101属于一个数据库，管理节点101用于管理相应数据库中的数据节点102。

本申请实施例中，管理节点101可以为单独的一个节点，或者多个数据节点102中指定数据节点或者选举得到的数据节点，其可以为一个服务器或者由多个服务器组成的服务器集群。管理节点101用于在接收到应用程序发送的SQL语句后，生成该SQL语句的执行计划，以控制管理节点101所管理的数据节点执行该执行计划。其中，执行计划用于指示执行的动作，以及执行动作的先后顺序等。也即是在什么时候做什么动作等。

该优化节点103用于对管理节点101进行执行计划的干预(也称优化)。

在一种实现方式中，每个数据节点可以为一个服务器或者由多个服务器组成的服务器集群；在另一实现方式中，每个数据节点表征数据库系统的一个设定的最小处理单元。示例的，每个数据节点可以为一个虚拟机或一个容器，其管理和/或存储数据的一个应用实例或一个数据库执行进程。

需要说明的是，优化节点103可以集成在管理节点101上，示例的，数据库系统中的每个管理节点101上可以集成一个优化节点103，或者，数据库系统中的指定的管理节点101上可以集成一个优化节点103。优化节点103也可以独立设置在管理节点101之外，当优化节点103设置在管理节点101之外时，管理节点101提供接口，以供优化节点103对管理节点101的执行计划进行干预。当优化节点103独立设置在管理节点101之外，可以减少对管理节点101性能的影响。

图2是本申请实施例提供的一种执行计划的处理方法的流程示意图。该方法可以由前述数据库系统10执行。后续实施例以对一个管理节点进行执行计划干预为例进行说明，假设该管理节点为第一管理节点，与该第一管理节点对应的数据库为第一数据库，对其他管理节点进行执行计划干预的过程可以参考对该第一管理节点进行执行计划干预的过程。如图2所示，该执行计划的处理方法(即干预过程)包括：

步骤201、数据库系统执行SQL语句的第一执行计划。

用户需要对第一数据库进行数据操作(如数据查询操作)时，可以通过应用程序向第一管理节点输入SQL语句，第一管理节点在接收到该SQL语句后，会根据第一数据库的优化规则(rule based on optimizer，RBO)信息和/或优化成本(cost based on optimizer，CBO)信息来生成执行计划，并在生成该执行计划之后的一段时间内一直沿用该执行计划。

其中，优化规则信息可以包括分区表(table partition)的信息和/或可靠性指标(available indices)。

数据库具有分区功能时，将关系表划分为称为分区的多个子集，每个子集即为一个分区表。例如，当关系表中的记录个数超过指定记录个数阈值，即将关系表划分为多个分区表。该分区表的划分规则可以包括：按照入库日期划分和/或按照所在地划分等。例如，按照所在地将关系表中的数据划分得到的分区表包括：上海对应的分区表和北京对应的分区表。

可靠性指标为用于反映数据库的可靠性的指标，当数据库中的数据超出可靠性指标所指定的范围，数据库会出现不稳定的情况，也即是数据库不再可靠。例如，可靠性指标可以包括：允许中断时长和/或输入/输出(input/output，IO)上限。当数据库中的管理节点生成SQL语句的执行计划的时长超过该允许中断时长，或者，数据库中的管理节点生成SQL语句的可执行计划的IO次数超过IO上限，数据库会可能出现用户可察觉的业务中断，数据库系统出现损失。

优化成本信息可以包括数据库的统计信息。统计信息用于反映对应数据库的关系表的数据分布情况。例如表内不同类型的数据的分布比例，或者，不同类型的数据存储(或者主要存储)在哪些数据节点等。例如，第一数据库的关系表记录有索引为“男”和“女”的数据，该第一数据库的统计信息可以包括索引为“男”和“女”的数据在所有数据中的比例以及主要存储在哪些数据节点。其中，主要存储在哪些数据节点指的是大于指定阈值的数据存储在哪些数据节点。

本申请实施例假设步骤201中的SQL语句为输入第一管理节点的SQL语句，第一执行计划是第一管理节点基于该SQL语句生成的执行计划。则数据库系统执行该SQL语句的第一执行计划指的是第一管理节点控制其管理的数据节点执行该第一执行计划。

可选地，数据库系统在生成并执行第一执行计划后，会记录该第一执行计划，以供第一数据库在后续一段时间沿用该第一执行计划。

图3是本申请实施例提供一示意性的数据库系统中数据流向示意图。假设优化节点103独立于第一管理节点101a设置。第一管理节点101a在生成第一执行计划后，控制所管理的数据节点执行该第一执行计划(即使用该第一执行计划)，被执行后的第一执行计划存储在系统表1042中，系统表1042中存储的执行计划可以同步至指标数据库1041，优化节点103可以从指标数据库1041中获取第一执行计划，并检测第一执行计划的性能是否劣化。

可选地，该系统表用于记录数据库系统中当前使用(或称当前时段使用)的执行计划。该当前使用的执行计划指的是该执行计划首次被执行后持续被沿用(也即是未被替换掉)。由于数据库系统中的数据库可能有多个。在一种可选实现方式中，多个数据库可以分别对应设置系统表；在另一种可选实现方式中，多个数据库可以共用系统表。以第一数据库为例，对应的系统表记录了第一数据库当前使用的执行计划。由于第一管理节点近期获取的SQL语句可以有多个，每个SQL语句对应的当前使用的执行计划的数量为一个。因此，系统表记录了该第一管理节点的多个SQL语句的一一对应的多个执行计划，该多个执行计划包括该第一执行计划。第一管理节点在下次需要重复使用之前已执行的执行计划(也即是沿用该执行计划)时，会查询该系统表，以获取所需的执行计划。

可选地，系统表1042中存储的执行计划可以周期性同步至指标数据库1041；或者，在系统表1042中存储的执行计划存在更新时，系统表1042中存储的执行计划同步(即全量同步)至指标数据库1041；或者，在系统表1042中存储的执行计划存在更新时，系统表1042中更新的执行计划同步(即增量同步)至指标数据库1041。

与前述系统表1042的设置方式同理的，由于数据库系统中的数据库有多个。在一种可选实现方式中，多个数据库可以分别对应设置指标数据库；在另一种可选实现方式中，多个数据库可以共用指标数据库。以第一数据库为例，对应的指标数据库记录了第一管理节点的系统表每次同步的执行计划。该指标数据库至少包括第一管理节点的历史执行计划，还可以包括第一数据库当前使用的执行计划，该历史执行计划为使用时段位于当前使用的执行计划的使用时段之前的执行计划。例如，对于SQL语句的第一执行计划，其对应的历史执行计划为在生成第一执行计划之前已存在的该SQL语句的其他执行计划。该指标数据库是否包括第一数据库当前使用的执行计划，受到第一数据库表向指标数据库同步执行计划的频率的影响。通常情况下，指标数据库记录有第一管理节点所有已执行的执行计划(包括历史执行计划以及当前使用的执行计划)。假设指标数据库记录有第一管理节点所有已执行过的执行计划。由于第一管理节点近期获取的SQL语句可以有多个，每个SQL语句对应的所有已执行的执行计划的数量为至少一个。因此，指标数据库记录了该第一管理节点的多个SQL语句的一一对应的多个执行计划组，每个执行计划组包括对应的SQL语句的至少一个执行计划。

在一种可选方式中，优化节点可以从指标数据库1041获取SQL语句的第一执行计划。例如，在指标数据库1041中的第一管理节点的SQL语句对应的执行计划组(该执行计划组包括一个或多个执行计划)中，获取最新的执行计划作为第一执行计划。该最新的执行计划为同步时刻距当前时刻最近的执行计划。

在另一种可选方式中，优化节点可以从系统表1042获取SQL语句的第一执行计划。例如，将系统表1042记录的第一管理节点的SQL语句对应的执行计划作为第一执行计划。

需要说明的是，数据库系统当前使用的执行计划以及历史执行计划的存储方式还可以有其他方式。图3仅以当前使用的执行计划存储在系统表，历史执行计划存储在指标数据库为例进行说明，但并不对此进行限制。只要保证数据库系统能够有效区分和获取当前使用的执行计划以及历史执行计划即可。并且，图3中示意性地以系统表存储在一个数据库中为例进行说明，该系统表的存储方式还可以有其他方式，本申请实施例对此不做限定。

值得说明的是，数据库系统中生成但未被执行的计划也可以记录在指标数据库1041中，如此可以实现对数据库系统中的执行计划的监控，便于对数据库系统的性能进行分析。

步骤202、数据库系统分析SQL语句的第一执行计划的性能是否劣化。

由于软硬件环境变更(如扩容或内核升级新版本等)或数据库异常，可能导致第一管理节点当前使用的第一执行计划比之前使用的执行计划的性能要差，导致SQL语句的性能下降，甚至整个第一数据库性能的下降。在这种情况下，数据库系统(如优化节点)可以通过分析SQL语句的第一执行计划的性能是否劣化来确定是否进行第一执行计划的干预，以恢复SQL语句的性能。该分析SQL语句的第一执行计划的性能是否劣化的过程，包括：

步骤A1、数据库系统分析第一执行计划的运行指标是否异常。执行步骤A2或步骤A3。

运行指标用于反映对应的执行计划的运行效果，也可以反映对应的SQL语句的性能。通过第一执行计划的运行指标可以确定第一执行计划的性能。示例的，第一执行计划的运行指标包括以下的一种或多种：SQL语句的IO指标、时延(delay)、错误(error)信息、执行次数和处理时长。

其中，IO指标指的是；执行计划被执行所产生的IO次数；时延指的是执行计划被执行所产生的时延；错误信息指的是；执行计划被执行所产生的错误的内容，和/或，执行计划被执行所产生的不同类型的错误在产生的整体错误中的占比，也即是每种类型的错误的个数与整体错误个数的比值；执行次数指的是执行计划被执行的次数；处理时长可以为执行计划被执行时占用处理器的时长，例如占用中央处理器(CPU，central processing unit)的处理时长，该占用CPU的处理时长称为CPU时长(CPU time)。

可选地，数据库系统可以周期性分析运行指标是否出现异常。示例的，该分析周期的范围为1分钟至10分钟。

数据库系统(例如优化节点)可以在该数据库系统中的每个数据库所在主机(也称数据库主机)上布置代理(agent)模块，每个代理模块用于监测所部署的数据库主机上的运行指标对应的数据。示例的，每个代理模块可以采集所部署的数据库主机上的运行指标对应的数据，并周期性地将采集到数据发送至管理代理模块的节点，如优化节点。示例的，前述运行指标对应的数据的发送周期的范围为5秒至10分钟。

第一执行计划的运行指标可以有一个或多个，第一执行计划的运行指标中，每个运行指标与一个运行指标数据组对应，该运行指标数据组通常包括对应的运行指标的多个数据，该多个数据通常是在指定时长内采集的数据。例如，该指定时长为一天；该多个数据还可以是以指定采样间隔采集的数据。例如，该指定采样间隔为1秒。第一执行计划的运行指标中，每个运行指标还与一个历史运行指标数据组对应。

对于对应于同一运行指标的历史运行指标数据组和运行指标数据组，该历史运行指标数据组对应的采集时长(即采集数据组中的数据所对应的采集时长)与该运行指标数据组的采集时长相同，历史运行指标数据组的获取时段在运行执行数据组的获取时段之前。例如，两者的数据采集时长均为1天。可选地，该历史运行指标数据组中的数据个数与该运行指标数据组中的数据个数相同。例如，该历史运行指标数据组中的数据个数与该运行指标数据组中的数据个数均为1万个；可选地，该历史运行指标数据组中的数据与该运行指标数据组中的数据的获取时刻一一对应。例如，该历史运行指标数据组中的数据与该运行指标数据组中的数据均为一天之内以相同的采样间隔获取的，则示例的，历史运行指标数据组中9：00采样得到的数据与运行指标数据组中9:00采样得到的数据对应，历史运行指标数据组中9：01采样得到的数据与运行指标数据组中9:01采样得到的数据对应。

本申请实施例中，数据库系统分析第一执行计划的运行指标是否异常的过程可以包括：

步骤A11、对于第一执行计划的运行指标中的每个运行指标，将该运行指标对应的运行指标数据组与对应的历史运行指标数据组对比，来确定每个运行指标是否异常。

步骤A12、基于每个运行指标的异常判定结果，确定第一执行计划的运行指标(即第一执行计划整体的运行指标)是否异常。

在前述步骤A11中，为了便于描述，假设第一运行指标为所述第一执行计划的运行指标中一个运行指标，第一运行指标对应的运行指标数据组为第一运行指标数据组，第一运行指标对应的历史运行指标数据组为第一历史运行指标数据组，则确定第一运行指标是否异常的过程可以包括以下两种实现方式：

第一种可实现方式，当第一运行指标数据组指示的性能低于第一历史运行指标数据组指示的性能，数据库系统确定该第一运行指标出现异常；当第一运行指标数据组指示的性能不低于第一历史运行指标数据组指示的性能，数据库系统确定该第一运行指标未出现异常(也即是正常)。

可选地，数据库系统分析第一运行指标数据组指示的性能低于第一历史运行指标数据组指示的性能的方式有多种。本申请实施例以以下两种方式为例进行说明：

第一种方式，数据库系统基于指定比较规则将第一运行指标数据组与第一历史运行指标数据组进行比较，以检测第一运行指标数据组指示的性能是否低于第一历史运行指标数据组指示的性能。

示例的，数据库系统维护有专家经验库，该专家经验库记载有基于专家经验确定的至少一个指定比较规则，数据库系统基于该指定比较规则，进行第一运行指标数据组与第一历史运行指标数据组的比较。

例如，该至少一个指定比较规则包括同比比较规则和/或环比比较规则，其中，环比比较规则，表示获取历史运行指标数据组与运行指标数据组的环比变化，采用该比较规则，可以基于环比下降率公式获取环比下降率。例如，该环比下降率公式包括：

环比下降率＝(运行指标数据组-历史运行指标数据组)/历史运行指标数据组×100％。

同比比较规则，表示获取历史运行指标数据组与运行指标数据组的同比变化，采用该比较规则，可以基于同比下降率公式获取同比下降率。例如，该同比下降率公式包括：

同比下降率＝(运行指标数据组-历史运行指标数据组)/|历史运行指标数据组|×100％。

示例的，当环比下降率大于第一比例阈值和/或同比下降率大于第二比例阈值，确定第一运行指标数据组指示的性能低于第一历史运行指标数据组指示的性能。

第二种方式，数据库系统通过将第一运行指标数据组的性能曲线与第一运行指标的性能基线进行比较，以检测第一运行指标数据组指示的性能是否低于第一历史运行指标数据组指示的性能。该过程如下：

步骤A111、数据库系统确定第一运行指标的性能基线(baseline)。

该第一运行指标的性能基线是基于历史运行指标数据组中的数据建立的用于反映SQL语句的关于第一运行指标的性能的基线。可选地，数据库系统可以基于第二人工智能模型以及第一历史运行指标数据组，生成该SQL语句的第一运行指标的性能基线。

在第一种可选方式中，数据库系统可以获取SQL语句的该第一运行指标的备选运行指标数据组，该备选运行指标数据组包括的数据的数量大于或等于第一历史运行指标数据组中的数据的数量；数据库系统再基于获取的第一运行指标的备选运行指标数据组，确定历史运行指标数据组；最后，数据库系统将第一历史运行指标数据组输入第二人工智能模型，由第二人工智能模型生成SQL语句的第一运行指标的性能基线。

可选地，数据库系统基于获取的该第一运行指标的备选运行指标数据组，确定第一历史运行指标数据组的方式可以有如下几种：

第一种：在备选运行指标数据组中筛选目标采集时长的数据，以得到第一历史运行指标数据组。该目标采集时长的数据可以是在备选运行指标数据组中随机筛选的，也可以是通过滑窗在备选运行指标数据组中筛选得到的对应性能最优的数据，该滑窗的宽度可以为该目标采集时长对应宽度。

第二种：备选运行指标数据组包括M个目标采集时长的子数据组，将M个子数据组的平均数据确定为第一历史运行指标数据组，也即是，第一历史运行指标数据组中每个数据为M个子数据组中对应数据的均值。如，备选运行指标数据组包括4天的数据，目标采集时长为1天，则一个子数据组的数据为一天的数据，则将该4天的数据的平均数据作为第一历史运行指标数据组。

值得说明的是，第一历史运行指标数据组还可以有其他确定方式，例如根据专家经验确定，本申请实施例只是对此示意性说明，并不进行限定。

在第二种可选方式中，数据库系统可以获取SQL语句的第一运行指标的备选运行指标数据组，该备选运行指标数据组包括的数据的数量大于或等于历史运行指标数据组中的数据的数量；数据库系统将获取的第一运行指标的备选运行指标数据组输入第二人工智能模型，由第二人工智能模型生成SQL语句的第一运行指标的性能基线。如此，第二人工智能模型先获取SQL语句的第一历史运行指标数据组，再生成运行指标的性能基线。

通常第一执行计划的运行指标中的每个运行指标对应一个第二人工智能模型，对于第一运行指标，对应的第二人工智能模型可以由该第一运行指标的多个历史运行指标数据组作为训练样本训练得到。其中，对应于前述第一种可选方式，训练用的每个历史运行指标数据组中的数据的数量与历史运行指标数据组中的数据的数量相同；对应于前述第二种可选方式，训练用的每个历史运行指标数据组中的数据的数量与备选历史运行指标数据组中的数据的数量相同。

值得说明的是，前述SQL语句的第一历史运行指标数据组可以周期性更新或者在接收到更新指令后更新，第一性能指标的性能基线也相应更新。如此可以保证第一历史运行指标数据组可以更能反映SQL语句的第一性能指标的历史性能。

运行指标的性能基线由人工智能模型生成，在保证性能基线的准确性的基础上，还可以提高性能基线的获取效率。

可选地，数据库系统还可以通过其他方式获取第一运行指标的性能基线，例如通过统计模型生成该性能基线，或者，通过人工绘制的方式获取该性能基线。

示例的，如图4所示，图4是本申请实施例提供的一种第一运行指标的性能基线的示意图。该性能基线可以位于二维坐标系中。例如，该性能基线包括高位线、低位线和中位线，其中，该二维坐标系中，横轴表示采集时刻，纵轴表示运行指标的数值大小。该高位线为基于第一历史运行指标数据组中的最大值确定的直线，其通常为经过该最大值的平行于横轴的直线；该低位线为基于第一历史运行指标数据组中的最小值确定的直线，其通常为经过该最小值的平行于横轴的直线；该中位线基于第一历史运行指标数据组中的数据确定的位于高位线和底线之间的直线，该中位线通常为经过该中位值的平行于横轴的直线，该中位值为第一历史运行指标数据组中的数据的平均值。

值得说明的是，本申请实施例提供的一种运行指标的性能基线还可以有其他绘制方式，本申请实施例对此不做限定。

步骤A112、数据库系统确定第一运行指标数据组的性能曲线。执行步骤A113或步骤A114。

第一运行指标数据组在第一运行指标的性能基线所在坐标系中可以形成一个性能曲线。数据库系统可以直接在该坐标系中标定第一运行指标数据组的性能曲线。例如将第一运行指标数据组的每两个相邻的数据对应的数值点采用线段连接得到该性能曲线。

步骤A113、当第一运行指标数据组的性能曲线与SQL语句的第一运行指标的性能基线不匹配时，数据库系统确定第一运行指标数据组指示的性能低于SQL语句的第一历史运行指标数据组指示的性能。

数据库系统将第一运行指标数据组的性能曲线与第一运行指标的性能基线进行比较。当第一运行指标数据组的性能曲线与SQL语句的第一运行指标的性能基线不匹配时，数据库系统确定第一运行指标数据组指示的性能低于SQL语句的第一历史运行指标数据组指示的性能。

第一运行指标数据组的性能曲线与对应的性能基线匹配的条件是预先设置的，其可以有多种设置方式。示例的，该匹配的条件指的是：该性能曲线上的数值点偏离性能基线的程度在指定程度范围内。也即是数值点偏离性能基线的程度在指定程度范围内，第一运行指标数据组的性能曲线与对应的性能基线匹配；当数值点偏离性能基线的程度在不在指定程度范围内，第一运行指标数据组的性能曲线与对应的性能基线不匹配。

可选地，曲线上的数值点偏离性能基线的程度可以由该数值点与性能基线的距离反映。例如，当性能基线包括高位线、低位线和中位线时，曲线上的数值点偏离性能基线的程度可以由该数值点与高位线、低位线和中位线中至少一者的距离反映。示例的，当该数值点到中位线的距离大于第一指定距离阈值；或者，当该数值点到中位线的距离大于第一指定距离阈值，且该数值点到高位线的距离大于第二指定距离阈值；或者，当该数值点到中位线的距离大于第一指定距离阈值，且该数值点到低位线的距离大于第三指定距离阈值，确定该数值点偏离性能基线。

如图5所示，图5是本申请实施例提供的一种第一运行指标数据组的性能曲线与第一运行指标的性能基线的比较场景示意图。通过比较性能曲线与性能基线是否匹配，可以确定第一运行指标数据组指示的性能是否低于SQL语句的第一历史运行指标数据组指示的性能。

步骤A114、当第一运行指标数据组的性能曲线与SQL语句的第一运行指标的性能基线匹配时，数据库系统确定第一运行指标数据组指示的性能不低于SQL语句的第一历史运行指标数据组指示的性能。

值得说明的是，数据库系统也可以基于第一运行指标数据组，直接在性能基线所在坐标系中标定与该第一运行指标数据组对应的数值点(通常为一组离散的数值点)。无需确定第一运行指标数据组对应的性能曲线。则前述步骤A112可以删除，步骤A113替换为当第一运行指标数据组的数值点与SQL语句的运行指标的性能基线不匹配时，数据库系统确定第一运行指标数据组指示的性能低于SQL语句的第一历史运行指标数据组指示的性能。步骤A114替换为当运行指标数据组的数值点与SQL语句的运行指标的性能基线匹配时，数据库系统确定第一运行指标数据组指示的性能不低于SQL语句的第一历史运行指标数据组指示的性能。

第一运行指标数据组的数值点与对应的性能基线匹配的条件是预先设置的，其可以有多种设置方式。示例的，该匹配的条件指的是：第一种：第一运行指标数据组的数值点中偏离性能基线的数值点的个数小于指定个数阈值，或者，第二种：第一运行指标数据组的数值点中偏离性能基线的数值点占数值点总数的比例小于指定比例阈值。

可选地，数值点偏离性能基线的程度可以由该数值点与性能基线的距离反映。例如，当性能基线包括高位线、低位线和中位线时，数值点偏离性能基线的程度可以由该数值点与高位线、低位线和中位线中至少一者的距离反映。相关解释可以参考前述曲线上的数值点偏离性能基线的程度的解释。

如图6所示，图6是本申请实施例提供的一种第一运行指标数据组的数值点与第一运行指标的性能基线的比较场景示意图。通过比较第一运行指标数据组的对应的多个离散数值点与性能基线是否匹配，可以确定第一运行指标数据组指示的性能是否低于第一历史运行指标数据组指示的性能。例如，假设匹配条件为前述第一种匹配条件，6个数值点中偏离性能基线的数值点个数为4个，若指定个数阈值为3，由于第一运行指标数据组的数值点中偏离性能基线的数值点的个数大于指定个数阈值，则第一运行指标数据组的对应的6个离散数值点与性能基线不匹配，相应的，确定第一运行指标数据组指示的性能低于第一历史运行指标数据组指示的性能。

第二种可实现方式，数据库系统通过AI模型来识别该第一运行指标是否出现异常。该过程如下：

数据库系统将第一运行指标数据组输入第一人工智能模型，当第一人工智能模型输出指示第一运行指标数据组异常的指示信息，确定第一运行指标出现异常。

其中，第一运行指标数据组中的内容可以参考前第一种可实现方式中的介绍。指示信息的结构可以有多种，在一种可选方式中，当每次向第一人工智能模型输入一个运行指标数据组时，指示信息可以包括指示标签(或称分类标签)，该指示标签用于标识输入第一人工智能模型的运行指标数据组是否异常；在另一种可选方式中，当每次向第一人工智能模型输入多个运行指标数据组时，指示信息可以包括携带有指示标签的运行指标数据组，也即是输出的运行指标数据组与输入的运行指标数据组相同，但每个运行指标数据组携带有指示标签；在又一种可选方式中，当每次向第一人工智能模型输入至少一个运行指标数据组时，指示信息可以包括出现异常的运行指标数据组，也即是仅输出的异常的运行指标数据组，不输出正常的运行指标数据组。

值得说明的是，通常一个执行计划的运行指标中的每个运行指标对应一个第一人工智能模型，对于同一运行指标，其对应的第一人工智能模型可以由该运行指标对应的多个历史运行指标数据组作为训练样本训练得到。

前述两种可实现方式可以根据实际情况进行结合，例如，当获取的运行指标数据组有多个时，例如获取了多个SQL语句对应的运行指标数据组，或者获取了一个SQL语句的一个运行指标的多个运行指标数据组时，可以先执行第一种可实现方式提供的方法，以进行异常的运行指标数据组的粗筛选，该粗筛选过程存在一定的误差，可能出现把非异常的运行指标数据组确定为异常的运行指标数据组的情况；再对粗筛选得到的(例如粗筛选结果为异常的)运行指标数据组执行第二种可实现方式提供的方法，以进行异常的运行指标数据组的精筛选。

以第一执行计划为例，对于第一执行计划的运行指标中的每个运行指标，当该运行指标数据组指示的性能低于SQL语句的历史运行指标数据组指示的性能，将运行指标数据组输入第一人工智能模型，当第一人工智能模型输出指示运行指标数据组异常的指示信息，确定第一执行计划的运行指标数据组出现异常，相对于前述第一种可实现方式，可以提高确定运行指标数据组异常的精确度。当该运行指标数据组指示的性能不低于SQL语句的历史运行指标数据组指示的性能，无需将运行指标数据组输入第一人工智能模型，相对于前述第二种可实现方式，可以减少第一人工智能模型的运算代价。

因此，采用第一种可实现方式和第二种可实现方式结合的方式，相对于仅执行第一种可实现方式提供的方法可以提高筛选精度，相对于仅执行第二种可实现方式提供的方法，可以提高筛选效率。

前述步骤A11中，确定第一执行计划的运行指标中其他运行指标是否异常的过程参考确定第一运行指标是否异常的过程。本申请实施例对此不再赘述。

在前述步骤A12中，数据库系统基于每个运行指标的异常判定结果，确定第一执行计划的运行指标是否出现异常的方式可以有多种，本申请实施例以以下几种可选方式为例进行说明：

在第一种可选方式中，当第一执行计划的至少一个运行指标出现异常，确定第一执行计划的运行指标出现异常；当第一执行计划的所有运行指标均未出现异常，确定第一执行计划的运行指标未出现异常。

在第二种可选方式中，基于每个运行指标的异常判定结果，确定第一执行计划的运行指标分数，当该运行指标分数大于指定分数阈值，确定该第一执行计划的运行指标出现异常；当该运行指标分数不大于指定分数阈值，确定该第一执行计划的运行指标未出现异常。也即是该运行指标分数越高，出现异常的概率越高。

其中，运行指标分数S满足分数计算公式：

其中，Xi表示第i个运行指标对应的运行指标数据组的异常等级，1≤i≤N，N为运行指标的总数，Pi为第i个运行指标的权值，Pi是由第i个运行指标的重要性(或称优先级)确定的。每个运行指标的异常等级是基于每个运行指标的异常判定结果确定的，该异常等级反映运行指标对应的运行指标数据组中数据的异常程度，通常出现异常的数据的个数越多，该异常等级越高。S表示N个运行指标对应的运行指标数据组的异常等级的加权和。

值得说明的是，前述第二种可选方式是以运行指标分数与出现异常的概率正相关的方式定义运行指标分数，实际实现时，还可以定义与出现异常的概率负相关的另一种运行指标分数，也即是运行指标分数越高，出现异常的概率越低，分数计算公式也相应调整，例如更新的运行指标分数S’为1/S，S为前述运行指标分数。本申请实施例对此不做赘述。

步骤A2、当第一执行计划的运行指标出现异常，确定SQL语句的第一执行计划的性能劣化。

步骤A3、当第一执行计划的运行指标未出现异常，确定SQL语句的第一执行计划的性能未出现劣化。

步骤203、在分析到SQL语句的第一执行计划的性能劣化后，数据库系统获取SQL语句的第二执行计划。

可选地，第二执行计划的性能与第一执行计划的性能不同。进一步可选地，第二执行计划的性能优于第一执行计划的性能。数据库系统获取SQL语句的第二执行计划的方式可以有多种，本申请实施例以以下两种获取方式为例进行说明：

第一种获取方式：数据库系统获取SQL语句的历史执行计划；当历史执行计划的性能优于第一执行计划的性能时，将历史执行计划确定为第二执行计划。

由于在第一执行计划之前，数据库系统(如优化节点或第一管理节点)可能生成过SQL语句的其他执行计划(也即是该其他执行计划是在第一执行计划之前生成的执行计划)，由于第一执行计划是当前使用的执行计划，可知该其他执行计划已经成为历史的执行计划，数据库系统可以在SQL语句的其他执行计划中确定历史执行计划，以判定该历史执行计划是否可以作为第二执行计划。示例的，该历史执行计划可以是SQL语句的其他执行计划中性能最优的执行计划、历史使用时间最长的执行计划或符合其他设定条件的执行计划。

数据库系统可以比较历史执行计划的性能与该第一执行计划的性能，以确定两者的性能优劣。比较历史执行计划的性能与该第一执行计划的性能的方式可以有多种。假设运行指标分数与出现异常的概率正相关，数据库系统可以确定第一执行计划的运行指标分数，并获取历史执行计划的运行指标分数，数据库系统比较两者的运行指标分数，当第一执行计划的运行指标分数小于历史执行计划的运行指标分数，确定第一管理节点生成的第一执行计划的性能优于历史执行计划的性能；当第一执行计划的运行指标分数不小于历史执行计划的运行指标分数，确定第一管理节点生成的第一执行计划的性能不优于历史执行计划的性能。第一执行计划的运行指标分数的确定方式可以参考前述步骤A12中第二种可选方式。

历史执行计划的运行指标分数的确定方式可以有多种，本申请实施例以以下几种为例进行说明：

在一种可选示例中，请参考步骤202，由于每次采用SQL语句的一个新的执行计划，数据库系统都会分析该执行计划的性能是否劣化，在分析该执行计划的性能是否劣化的过程，会获取指示该执行计划的性能的指示信息，例如该指示信息包括该执行计划的运行指标对应的数据(例如该执行计划的运行指标中，每个运行指标对应的运行指标数据组)或执行计划的运行指标分数，则数据库系统可以记录获取的性能的指示信息。如此，数据库系统记录有每个历史执行计划的指示信息。则数据库系统可以基于预先记录的历史执行计划的指示信息，确定历史执行计划的运行指标分数，该运行指标分数反应历史执行计划的性能。

在另一种可选示例中，数据库系统中，生成的执行计划中携带预估的性能开销，该性能开销越大指示执行计划的性能越差。数据库系统可以基于该性能开销，确定历史执行计划的运行指标分数，该运行指标分数反应历史执行计划的性能。示例的，该性能开销可以包括预估的该执行计划的运行指标的数据。例如，历史执行计划的性能开销包括：预估的历史执行计划的IO指标、时延、错误信息、执行次数和/或处理时长的数据(或由该数据转化得到的异常等级)。该运行指标分数基于预估的前述每个运行指标的数据确定，确定方式可以参考前述步骤A12中第二种可选方式。又例如，该性能开销可以直接包括预估的运行指标分数。

本申请实施例还可以以其他方式比较历史执行计划的性能与该第一执行计划的性能，例如将历史执行计划的运行指标与该第一执行计划的运行指标一一进行对比，基于对比结果，确定历史执行计划的性能是否优于第一执行计划的性能，本申请实施例对此不做限定。

由于历史执行计划已经预先生成，因此采用该第一种获取方式，可以快速获取优于第一执行计划的性能的历史执行计划作为第二执行计划，能够实现执行计划的快速优化，提高优化效率。

第二种获取方式：数据库系统生成SQL语句的第二执行计划。

可选地，生成SQL语句的第二执行计划所占用的计算资源大于生成SQL语句的第一执行计划所占用的计算资源，和/或，生成SQL语句的第二执行计划的时长大于生成SQL语句的第一执行计划的时长。

第一执行计划通常是第一管理节点在线生成的。为了避免时延过长，影响用户体验，第一执行计划生成的时长有一定的限制。示例的，该第一执行计划需要在第一时长阈值内生成。例如，在步骤201中，第一管理节点可以执行以下步骤：基于第一数据库的优化规则信息和/或优化成本信息，生成多个备选执行计划，并在该多个备选执行计划中确定第一执行计划。该生成备选执行计划以及确定第一执行计划的时长需要在该第一时长阈值内。

并且，为了避免对计算资源的占用，影响其他用户业务，第一执行计划生成时所占用的计算资源也有一定的限制。示例的，生成该第一执行计划占用的计算资源小于第一计算资源阈值。也即是，前述该生成备选执行计划以及确定第一执行计划的过程所占用的计算资源小于第一计算资源阈值。其中，计算资源可以包括第一管理节点运行时所需的CPU资源、内存资源和/或硬盘资源等。

其中，第一时长阈值可以基于前述可靠性指标中的允许中断时长确定，例如，第一时长阈值小于或等于该允许中断时长；第一计算资源阈值可以基于前述可靠性指标中的IO上限或其他与计算资源相关的参数确定。

而本申请实施例中，数据库系统(例如优化节点)可以基于第一数据库的优化规则信息和/或优化成本信息，生成多个备选执行计划，并在该多个备选执行计划中确定第二执行计划。但该确定第二执行计划的过程可以是一个离线计算的过程，由于第二执行计划在离线生成时不影响第一数据库的正常业务，也不受第一数据库的业务的约束，因此可以占用较多的时间和/或计算资源来确定SQL语句的第二执行计划。在这种情况下，该数据库系统生成备选执行计划以及确定第二执行计划的过程均可以参考前述生成第一执行计划的对应过程。也即是，第二执行计划和第一执行计划的生成原理可以相同。但是，生成SQL语句的第二执行计划所占用的计算资源；和/或，生成SQL语句的第二执行计划的时长不受约束，或者相对于生成第一执行计划的过程受到较少的约束。如此，前述数据库系统基于第一数据库的优化规则信息和/或优化成本信息，生成多个备选执行计划指的是，数据库系统基于第一数据库的优化规则信息和/或优化成本信息中其他信息，生成多个备选执行计划，该其他信息是优化规则信息和/或优化成本信息中除与计算资源相关和计算时间相关的信息之外的信息。

由此可知，数据库系统生成SQL语句的第二执行计划所占用的计算资源大于生成SQL语句的第一执行计划所占用的计算资源；和/或，生成SQL语句的第二执行计划的时长大于生成SQL语句的第一执行计划的时长。

示例的，可以为数据库系统设置第二时长阈值，以及第二计算资源阈值。该第二时长阈值大于第一时长阈值，第二计算资源阈值大于第一资源阈值。该数据库系统在该第二时长阈值，以及第二计算资源阈值的限制下生成备选执行计划以及再在备选执行计划中确定第二执行计划，该过程可以参考前述生成第一执行计划的对应过程。

由于生成第二执行计划受到的限制较少，因此通常性能优于第一执行计划的性能。假设第一执行计划由第一管理节点生成，第二执行计划由优化节点生成。在第一种示例中，第一管理节点生成的备选执行计划个数(如100个)小于优化节点生成的备选执行计划个数(如10000个)，示例的，虽然第一管理节点遍历生成的该多个备选执行计划，以确定第一执行计划，同理，优化节点遍历生成的该多个备选执行计划，以确定第二执行计划，两个遍历过程相同，但是由于优化节点的可选择的备选执行计划数量更多，最终确定的第二执行计划优于第一执行计划的概率较高。

在第二种示例中，第一管理节点生成的备选执行计划个数与优化节点生成的备选执行计划个数(如均为10000个)，但是，受到第一时长阈值的限制，第一管理节点无法遍历(只能枚举)生成的该多个备选执行计划，以确定第一执行计划，而优化节点可以遍历生成的该多个备选执行计划，以确定第二执行计划。虽然生成相同个数的备选执行计划，但是第一管理节点和优化节点扫描的备选执行计划的个数不同，最终确定的第二执行计划优于第一执行计划的概率较高。

为了便于读者理解，假设第一数据库的优化规则信息指示5毫秒返回SQL语句的查询数据，第一时长阈值为0.5毫秒。

继续以前述第二种示例为例，假设第一管理节点生成了1000个备选执行计划，在0.5毫秒内，第一管理节点仅能扫描该1000个备选执行计划中的100个备选执行计划。则第一管理节点基于该100个备选执行计划，确定第一执行计划。假设优化节点生成了1000个备选执行计划，与前述第一管理节点生成的1000个备选执行计划相同，优化节点遍历该1000个备选执行计划，从而在该1000个备选执行计划中确定第二执行计划。

综上可知，由于在生成时间和/或占用的计算资源上减少了对生成执行计划过程的限制，可以保证最终确定的第二执行计划的性能优于第一执行计划的性能。

值得说明的是，前述第一种获取方式和第二种获取方式还可以结合使用。例如，若数据库系统无法获取SQL语句的历史执行计划(例如，SQL语句不存在其他执行计划，或者存在的其他执行计划不满足条件，导致无法获取历史执行计划)；或者，虽然可以获取历史执行计划，但是历史执行计划的性能不优于第一执行计划的性能，则在执行前述第二种获取方式。

可选地，数据库系统还可以采用其他方式获取SQL语句的第二执行计划。例如，用户可以输入执行计划更新指令，相应的，数据库系统可以接收执行计划更新指令，该执行计划更新指令包括第二执行计划。

在本申请实施例中，用户还可以控制是否进行执行计划的干预。则在前述步骤203之前，也即是数据库系统在分析到SQL语句的第一执行计划的性能劣化后，数据库系统还可以发送告警指示信息。该告警指示信息指示该SQL语句的第一执行计划性能劣化。可选地，该告警指示信息可以包括SQL语句，即产生性能劣化的SQL语句；该告警指示信息还可以包括指示进行执行计划的干预的任务。用户可以基于该告警指示信息知晓当前出现性能劣化的SQL语句，并判定是否进行执行计划的干预。相应的，在步骤203中，数据库系统在接收到执行计划优化指令后，获取SQL语句的第二执行计划。该执行计划优化指令用于指示对劣化的执行计划进行干预。可选地，该执行计划优化指令和该执行计划更新指令可以为同一指令。

可选地，该告警指示信息可以通过用户界面呈现。图7是本申请实施例提供的一种示意性的用户界面30的示意图，该用户界面30除了告警指示信息301之外，还可以呈现确定选项302、禁止选项303和/或延迟优化选项304。当用户确定进行执行计划的优化后，触发该确定选项302，相应的，数据库系统接收到执行指令，基于该执行指令进行执行计划的优化；当用户确定禁止进行执行计划的优化后，触发该禁止选项303，相应的，数据库系统接收到禁止执行指令，基于该禁止执行指令禁止进行执行计划的优化；当用户确定延期进行执行计划的优化后，触发该延迟优化选项304，相应的，数据库系统接收到延期执行指令，基于该延期执行指令在到达该延期执行指令所指示的时间点后进行执行计划的优化。其中，延迟优化选项指示的时间点可以是预先设置的时间点，如关机时间点或开机时间点；或者，延迟优化选项指示的时间点可以是用户设置的时间点，如一小时后或者一天以后。

本申请实施例中，通过用户界面将告警指示信息呈现给用户，由用户来控制是否进行执行计划的优化，可以避免后台自动进行执行计划的优化影响用户的操作或影响正在执行的用户业务，提高执行计划干预的时间上的灵活性，提高用户体验。

步骤204、数据库系统将第二执行计划转化为与第一管理节点匹配的第二执行计划。

数据库系统获取的第二执行计划在被使用时需要由第一管理节点解析。虽然该第二执行计划可以由第一管理节点解析，但是可能该第二执行计划并不完全适配于第一管理节点，从而影响第一管理节点解析该第二执行计划的速度，进而导致该第一管理节点产生较长的解析时延，影响第二执行计划被加载和使用的效率。

本申请实施例中可以将第二执行计划转化为与第一管理节点匹配的第二执行计划，以保证第一管理节点能够快速解析转化后的第二执行计划，从而减少第一管理节点产生的解析时延，提高第一管理节点对第二执行计划的加载和使用效率。

示例的，数据库系统可以采用查询对应关系的方式，将第二执行计划转化为与第一管理节点匹配的第二执行计划，该过程包括：数据库系统查询指定的管理节点与执行计划格式的对应关系，得到第一管理节点对应的执行计划格式；数据库系统将第二执行计划转化为符合该执行计划格式的第二执行计划。

步骤205、优化节点执行所述第二执行计划来替换对所述第一执行计划的执行。

在第一种可选方式中，围优化节点可以不执行前述步骤204，直接执行所述第二执行计划来替换对所述第一执行计划的执行；在另一种可选方式中，优化节点可以执行采用步骤204转化得到的第二执行计划来替换对所述第一执行计划的执行。

在一种示意性实现方式中，第二执行计划携带著录提示标签(hint)，该著录提示标签用于标识对应的执行计划为更新后的执行计划(或称干预后的执行计划)。示例的，数据库系统(如优化节点)可以在第二执行计划中添加著录提示标签，第一管理节点基于该著录提示标签可以确定对应的执行计划是数据库系统(如优化节点)干预后的执行计划，并不是第一管理节点本身正常生成(如在线生成的)的执行计划。该著录提示标签可以由一个或多个字符组成，该字符可以为数字字符或字母字符等等。

可选地，请继续参考图3，添加了著录提示标签的第二执行计划仍然存储在前述系统表1042中。第二执行计划会替换掉该系统表1042中记录的第一执行计划。在一种可选方式中，可以先删除第一执行计划，再添加第二执行计划；在另一种可选方式中，可以采用第二执行计划覆盖第一执行计划。传统的数据库系统中的执行计划不添加著录提示标签，本申请实施例通过在第二执行计划上添加著录提示标签，可以与第一管理节点101a正常生成的执行计划进行区分。第一管理节点101a将添加著录提示标签的第二执行计划加载，而通常第二执行计划的性能优于第一执行计划的性能，如此实现执行计划的优化。

在另一种示意性实现方式中，可以采用分区存放的方式来区分更新的执行计划和正常生成的执行计划。示例的，数据库系统(如优化节点)将第二执行计划存储在其他系统表中，该其他系统表用于记录更新的执行计划，当该更新的执行计划不允许被使用(例如停止对第一管理节点的执行计划的干预过程)后，可以清空该其他系统表中第一管理节点对应的更新的执行计划。如此，其他系统表通常有以下两种状态，一种是存储有第一管理节点的一个更新的执行计划的状态，另一种是未存储第一管理节点的更新的执行计划的状态。

第一管理节点在需要加载SQL语句的执行计划时，可以先查询其他系统表，若其他系统表存储有SQL语句的执行计划，则加载该执行计划；若其他系统表未存储SQL语句的执行计划，加载前述系统表中的SQL语句的执行计划。

值得说明的是，前述204和步骤205是以第一执行计划的性能劣化为例进行说明的，当在步骤202分析得到第一执行计划的性能为劣化，则可以保持第一执行计划的使用，则在此情况下，如图3所示，第一管理节点101a在系统表1042获取的仍然是第一执行计划(图3未示出)。

步骤206、在新版本的执行计划的性能优于第二执行计划的性能时，数据库系统执行新版本的执行计划来替换对所述第二执行计划的执行。

若软硬件环境变更，或者第一管理节点到达生成新版本的执行计划的周期后，数据库系统(如第一管理节点)会生成新版本的执行计划，假设该新版本的执行计划为第三执行计划。数据库系统可以分析该第三执行计划的性能，若第三执行计划的性能优于第二执行计划的性能，则数据库系统执行新版本的执行计划来替换对所述第二执行计划的执行。当第三执行计划的性能未优于第二执行计划的性能，说明第二执行计划的性能仍然较优，数据库系统仍然保持第二执行计划的执行。在这种情况下，数据库系统在每次生成一个第三执行计划后，比较第二执行计划的性能与该第三执行计划的性能，直至第三执行计划的性能优于第二执行计划的性能，数据库系统执行新版本的执行计划来替换对所述第二执行计划的执行。

其中，比较第二执行计划的性能与该第三执行计划的性能的方式可以有多种。例如，数据库系统中，生成的执行计划中携带预估的性能开销，该性能开销越大指示执行计划的性能越差。假设运行指标分数与出现异常的概率正相关，数据库系统可以基于该性能开销，确定第三执行计划的运行指标分数，并获取第二执行计划的运行指标分数，数据库系统比较两者的运行指标分数，当第三执行计划的运行指标分数小于第二执行计划的运行指标分数，确定第三执行计划的性能优于第二执行计划的性能；当第三执行计划的运行指标分数不小于第二执行计划的运行指标分数，确定第三执行计划的性能不优于第二执行计划的性能。

示例的，该性能开销可以包括预估的第三执行计划的运行指标对应的数据(即该执行计划的运行指标中，每个运行指标对应的运行指标数据组)。例如，第三执行计划的性能开销包括：预估的第三执行计划的IO指标、时延、错误信息、执行次数和/或处理时长的数据(或由该数据转化得到的异常等级)。该运行指标分数基于预估的前述每个运行指标的数据确定，确定方式可以参考前述步骤A12中第二种可选方式。又例如，该性能开销可以直接包括预估的运行指标分数。

本申请实施例还可以以其他方式比较第二执行计划的性能与该第三执行计划的性能，例如将第二执行计划的运行指标与该第三执行计划的运行指标一一进行对比，基于对比结果，确定第三执行计划的性能是否优于第二执行计划的性能，本申请实施例对此不做限定。

可选地，数据库系统还可以采用其他方式获取SQL语句的第三执行计划(即前述新版本的执行计划)，例如，用户可以输入执行计划版本更新指令，相应的，数据库系统可以接收执行计划版本更新指令，该执行计划版本更新指令包括第三执行计划。

在本申请实施例中，用户还可以对数据库系统中的规则进行设置。则本申请实施例提供的执行计划的处理方法还可以包括：接收规则设置指令，该规则设置指令包括设置的规则。可选地，数据库系统中的规则可以包括以下至少一种：SQL性能对比规则、著录提示标签设置规则、告警规则和路由规则。

该SQL性能对比规则为指示数据库系统如何确定SQL语句的第一执行计划的性能是否劣化的规则。例如基于该SQL性能对比规则，数据库系统可以执行前述步骤A1至A3。该著录提示标签设置规则为指示数据库系统如何设置著录提示标签的规则。例如，基于著录提示标签设置规则，数据库系统可以采用前述步骤205提供的方法添加著录提示标签。告警规则为指示数据库系统如何告警的规则。例如，基于告警规则，数据库系统可以发出前述告警指示信息。路由规则为指示数据库系统如何存储获取的数据(如运行指标对应的数据)的规则。例如，基于路由规则，数据库系统可以将获取的运行指标数据组中的数据存储在指定存储空间中。

综上所述，本申请实施例在分析到第一执行计划的性能劣化后，会采用第二执行计划替换第一执行计划，以避免数据库使用性能劣化的第一执行计划，减少性能劣化的执行计划对数据库的影响，从而保证数据库的性能。可选地，该第二执行计划的性能优于第一执行计划的性能，从而有效保证数据库的性能。

需要说明的是，本申请实施例提供的执行计划的处理方法的步骤的先后顺序可以进行适当调整，步骤也可以根据情况进行相应增减，例如前述步骤202、204和206可以不执行，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化的方法，都应涵盖在本申请的保护范围之内，因此不再赘述。

本申请实施例的数据库系统支持对管理节点的执行计划的干预功能，该功能可以由多种方式触发。例如，在一种可选方式中，数据库系统接收到执行计划干预指令后，执行对管理节点的执行计划的干预过程，如开始执行步骤202至步骤206，也即是在接收到执行计划优化指令后，开始分析SQL语句的第一执行计划的性能是否劣化，该执行计划干预指令可以是用户通过应用程序触发，也可以由指定设备触发；在另一种可选方式中，数据库系统周期性地执行对第一管理节点的执行计划的干预过程，如步骤202至步骤206。

图8是本申请实施例提供的该数据库系统的结构示意图。如图8所示，该数据库系统包括优化节点，图8假设优化节点位于管理节点(图8未绘出)之外，优化节点包括处理(processing)模块、人工智能计算引擎、分析模块、操作模块和告警模块。其中，分析模块包括诊断子模块和优化子模块，操作模块包括集群管理子模块和实例管理子模块。

人工智能计算引擎可以存储有前述第一人工智能模型和前述第二人工智能模型，并基于存储的人工智能模型执行相应的计算。例如，执行前述步骤A111，和前述步骤A114提供的第二种方式所对应的计算。分析模块用于分析SQL语句的第一执行计划的性能是否劣化，并在确定第一执行计划的性能劣化后，进行第一执行计划的替换。其中，诊断子模块用于诊断SQL语句的第一执行计划的性能是否劣化，其可以执行前述步骤202；优化子模块用于在诊断子模块确定第一执行计划的性能劣化后，进行第一执行计划的替换，其可以执行前述步骤203至步骤205。操作模块用于对数据库系统中的操作进行管理，其中，集群管理子模块用于管理数据库集群，实例管理子模块用于管理数据库实例。告警模块用于发送告警指示信息。

该数据库系统还包括多个数据库，该多个数据库包括：一个或多个关系型数据库，一个或多个指标数据库以及配置数据库。

其中，关系型数据库为该数据库系统所主要维护的数据库，图8以关系型数据库共3个，分别为数据库1至3为例进行说明。每个数据库包括管理节点和该管理节点所管理的一个或多个数据节点，每个数据库可以提供系统视图、SQL指标和/或管理节点的应用程序接口(Application Programming Interface，API)。该SQL指标指的是前述SQL语句的执行计划的运行指标。管理节点API指的是数据库中的管理节点的API。

指标数据库用于存储本申请实施例提供的执行计划的处理方法所涉及的数据，本申请实施例中，指标数据库的个数可以根据存储的数据量的增长而增长。图8以指标数据库共3个，分别为指标数据库1至3为例进行说明。配置数据库用于存储数据库系统中的规则，如SQL性能对比规则、著录提示标签设置规则、告警规则和/或路由规则。该数据库系统维护有操作系统(operating system，OS)，该操作系统可以为Linux或Windows操作系统。该操作系统可以控制CPU、磁盘(disk)、存储器(memory)、网络(network)和/或主板(mainboard)等。

该数据库系统在原有的数据库服务的基础上，按照功能又增加了采集层、存储与处理层、服务层和页面(view)层。其中，采集层与存储与处理层之间具有API，服务层和页面层之间具有API。页面层可以提供可视化页面。通过该可视化页面，用户可以控制是否进行执行计划的干预，或者输入执行计划版本更新指令，或者输入执行计划干预指令。例如，该可视化页面可以呈现如图7所示的用户界面。

为了便于读者理解，本申请实施例基于图8所示的数据库系统的示意性的结构，对执行计划的处理方法进行示意性说明。优化节点可以在数据库系统中的每个数据库所在主机上布置代理模块，每个代理模块采集所部署的数据库主机上的运行指标对应的数据，并将采集到的数据发送至处理模块。示例的，代理模块可以采用消息队列(message queue，MQ)的方式将采集到的发送至处理模块，由处理模块对接收到的数据进行流式处理。并且处理模块可以将数据库系统的系统表(如前述实施例中的系统表)里存储的所有SQL语句的执行计划存储至与管理节点对应的指标数据库中。处理模块进行流式处理的方式可以分为在线(online)和离线(offline)两种方式。可选地，处理模块可以获取人工智能计算引擎计算得到的各个运行指标的性能基线，并将各个运行指标的性能基线存储至指标数据库中。可选地，用户可以通过前述规则设置指令设置路由规则，相应的，处理模块基于设置的路由规则在指标数据库中存储SQL语句的执行计划的运行指标对应的数据和/或各个运行指标的性能基线。假设数据库X为前述数据库1至3中的任一数据库，分析模块分析数据库X中的SQL语句的第一执行计划的性能是否劣化，并在确定第一执行计划的性能劣化后，由优化子模块获取所述SQL语句的第二执行计划，控制数据库X执行所述第二执行计划来替换对所述第一执行计划的执行。告警模块在达到告警条件后发出告警指示信息。

传统的数据库系统，由于每个执行计划会在一段时间(如几周)内持续使用，若该执行计划本身性能较差，会在该段时间内影响数据库的性能，严重的情况下会导致大规模数据库版本回退，造成长时间的业务中断。

而本申请实施例在分析到第一执行计划的性能劣化后，会采用第二执行计划替换第一执行计划，以避免数据库使用性能劣化的第一执行计划，减少性能劣化的执行计划对数据库的影响，从而保证数据库的性能。可选地，该第二执行计划的性能优于第一执行计划的性能时，可以有效保证数据库的性能，避免数据库版本回退，减少业务中断时长。

基于与上述实施例提供的执行计划的处理方法的同一构思，本申请实施例提供一种执行计划的处理方法，图9是本申请实施例提供的该执行计划的处理方法的流程示意图。该方法可以由前述数据库系统10执行。所述方法包括：

步骤401、数据库系统执行SQL语句的第一执行计划。

步骤401的过程可以参考前述步骤201的过程，本申请实施例对此不做赘述。

步骤402、数据库系统获取SQL语句的新版本的第二执行计划。

步骤402的数据库系统获取SQL语句的新版本的第二执行计划过程可以参考前述步骤206数据库系统获取SQL语句的新版本的执行计划(即第三执行计划)的过程，本申请实施例对此不做赘述。

例如，第二执行计划由管理节点生成，或者由用户通过执行计划版本更新指令输入。

可选地，获取该SQL语句的新版本的第二执行计划包括：生成该SQL语句的第二执行计划，该生成该SQL语句的第二执行计划的过程可以包括：基于管理节点所在数据库的优化规则信息和/或优化成本信息，生成多个备选执行计划；遍历该多个备选执行计划，得到该第二执行计划。

步骤403、在第二执行计划的性能优于第一执行计划的性能时，数据库系统执行第二执行计划来替换对第一执行计划的执行。

步骤403的过程可以参考前述步骤206数据库系统执行第三执行计划来替换对第二执行计划的执行的过程，本申请实施例对此不做赘述。其中，步骤403中的第二执行计划相当于步骤206中的第三执行计划，步骤403中的第一执行计划相当于步骤206中的第二执行计划。

值得说明的是，该执行计划的处理方法还支持前述实施例中提供的其他功能，例如在步骤403之前，例如在确定该第二执行计划的性能优于该第一执行计划的性能后，数据库系统将第二执行计划转化为与管理节点匹配的第二执行计划，该过程可以参考前述步骤204。本申请实施例对此不再赘述。

传统的数据库系统中，当管理节点生成新版本的执行计划后，直接执行新版本的执行计划来替换原执行计划的执行，而该新版本的执行计划会在一段时间(如几周)内持续使用，若该新版本的执行计划本身性能较差，会在该段时间内影响数据库的性能。严重的情况下会导致大规模数据库版本回退，造成长时间的业务中断。

而本申请实施例在新版本的第二执行计划的性能优于第一执行计划的性能时，数据库系统才执行第二执行计划来替换对第一执行计划的执行，以避免数据库采用性能劣化的新版本的执行计划，减少性能劣化的执行计划对数据库的影响，从而保证数据库的性能。并且，由于该第二执行计划的性能优于第一执行计划的性能，可以有效保证数据库的性能，避免数据库版本回退，减少业务中断时长。

图10是本申请实施例提供一种数据库系统50的框图，该数据库系统50包括：

执行模块501，用于执行结构化查询语言SQL语句的第一执行计划。获取模块502，用于在该SQL语句的第一执行计划的性能劣化时，获取该SQL语句的第二执行计划。该执行模块502还用于执行该第二执行计划来替换对该第一执行计划的执行。

本申请实施例中，执行模块在第一执行计划的性能劣化后，会采用第二执行计划替换第一执行计划，以避免数据库使用性能劣化的第一执行计划，减少性能劣化的执行计划对数据库的影响，从而保证数据库的性能。

可选地，该第二执行计划与该第一执行计划不同。

可选地，该第二执行计划的性能优于该第一执行计划的性能。该第二执行计划的性能优于第一执行计划的性能时，可以有效保证数据库的性能，避免数据库版本回退，减少业务中断时长。

可选地，该获取模块502，用于：获取该SQL语句的历史执行计划；当该历史执行计划的性能优于该第一执行计划的性能时，将该历史执行计划作为该第二执行计划。

可选地，该获取模块502，用于：生成该SQL语句的第二执行计划。

可选地，生成该SQL语句的第二执行计划所占用的计算资源大于生成该SQL语句的第一执行计划所占用的计算资源，和/或，生成该SQL语句的第二执行计划的时长大于生成该SQL语句的第一执行计划的时长。

图11是本申请实施例提供一种数据库系统50的框图，该数据库系统50包括：告警模块503，用于在该SQL语句的第一执行计划的性能劣化时，发送告警指示信息。可选地，该获取模块502，用于：在接收到执行计划优化指令后，获取该SQL语句的第二执行计划。

可选地，该执行模块501，还用于：在新版本的执行计划的性能优于该第二执行计划的性能时，执行该新版本的执行计划来替换对该第二执行计划的执行。

图12是本申请实施例提供另一种数据库系统50的框图，该数据库系统50还包括：确定模块504，用于当该第一执行计划的运行指标出现异常时，确定该SQL语句的第一执行计划的性能劣化。

可选地，该第一执行计划的运行指标包括以下的一种或多种：该第一执行计划的输入输出IO指标、时延、错误信息、执行次数和处理时长。

可选地，该确定模块504，用于：对于该第一执行计划的运行指标中的每个运行指标，当该运行指标对应的运行指标数据组指示的性能低于该运行指标对应的该SQL语句的历史运行指标数据组指示的性能，确定该运行指标出现异常；和/或，对于该第一执行计划的运行指标中的每个运行指标，将该运行指标对应的运行指标数据组输入第一人工智能模型，当该第一人工智能模型输出指示该运行指标异常的指示信息，确定该运行指标出现异常。

可选地，该确定模块504，用于：

对于该第一执行计划的运行指标中的每个运行指标，当该运行指标对应的运行指标数据组的性能曲线与该运行指标的性能基线不匹配时，确定该运行指标对应的运行指标数据组指示的性能低于该历史运行指标数据组指示的性能，该运行指标的性能基线基于该历史运行指标数据组确定。

图13是本申请实施例提供又一种数据库系统50的框图，该数据库系统50还包括：基线生成模块505，用于基于第二人工智能模型以及该历史运行指标数据组，生成该运行指标的性能基线。

值得说明的是，本申请实施例提供的一种数据库系统的结构还可以为前述图1或图8所示的数据库系统。

示例的，当数据库系统的结构为前述图1所示的数据库系统的结构时，前述执行模块501可以集成在管理节点101和数据节点102中，以由管理节点101和数据节点102配合完成执行模块501的功能，或者，前述执行模块501可以集成在管理节点101中，以由管理节点101完成执行模块501的功能；获取模块502、告警模块503、确定模块504和基线生成模块505中的一个或多个模块可以集成在优化节点103中，以由优化节点103完成该一个或多个模块的功能。

示例的，当数据库系统的结构为前述图8所示的数据库系统的结构时，前述执行模块501可以集成在数据库中，如数据库1至数据库3中的至少一个数据库中，以由该至少一个数据库完成执行模块501的功能；获取模块502可以集成在处理模块中，以由该处理模块完成获取模块502的功能，告警模块503的功能与图8中的告警模块的功能相同；确定模块504可以集成在分析模块中，以由该分析模块完成确定模块504的功能；基线生成模块505可以集成在人工智能计算引擎中，以由该人工智能计算引擎完成基线生成模块505的功能。

图14是本申请实施例提供又一种数据库系统60的框图，该数据库系统60包括：

执行模块601，用于执行结构化查询语言SQL语句的第一执行计划；获取模块602，用于获取该SQL语句的新版本的第二执行计划；该执行模块602还用于在该第二执行计划的性能优于该第一执行计划的性能时，执行该第二执行计划来替换对该第一执行计划的执行。

值得说明的是，本申请实施例提供的一种数据库系统的结构还可以为前述图1所示的数据库系统。

示例的，当数据库系统的结构为前述图1所示的数据库系统的结构时，前述执行模块601可以集成在管理节点101和数据节点102中，以由管理节点101和数据节点102配合完成执行模块601的功能，或者，前述执行模块601可以集成在管理节点101中，以由管理节点101完成执行模块601的功能；获取模块602可以集成在优化节点103中，以由优化节点103完成执行模块602的功能。

本申请实施例中，在新版本的第二执行计划的性能优于第一执行计划的性能时，执行模块才执行第二执行计划来替换对第一执行计划的执行，以避免数据库采用性能劣化的新版本的执行计划，减少性能劣化的执行计划对数据库的影响，从而保证数据库的性能。并且，由于该第二执行计划的性能优于第一执行计划的性能，可以有效保证数据库的性能，避免数据库版本回退，减少业务中断时长。

可选地，图15示意性地提供本申请该计算机设备的一种可能的基本硬件架构。

参见图15，计算机设备700包括处理器701、存储器702、通信接口703和总线704。

计算机设备700中，处理器701的数量可以是一个或多个，图15仅示意了其中一个处理器701。可选地，处理器701，可以是中央处理器(central processing unit，CPU)。如果计算机设备700具有多个处理器701，多个处理器701的类型可以不同，或者可以相同。可选地，计算机设备700的多个处理器701还可以集成为多核处理器。

存储器702存储计算机指令和数据；存储器702可以存储实现本申请提供的执行计划的处理方法所需的计算机指令和数据，例如，存储器702存储用于实现执行计划的处理方法的步骤的指令。存储器702可以是以下存储介质的任一种或任一种组合：非易失性存储器(例如只读存储器(ROM)、固态硬盘(SSD)、硬盘(HDD)、光盘)，易失性存储器。

通信接口703可以是以下器件的任一种或任一种组合：网络接口(例如以太网接口)、无线网卡等具有网络接入功能的器件。

通信接口703用于计算机设备700与其它计算机设备或者终端进行数据通信。

总线704可以将处理器701与存储器702和通信接口703连接。这样，通过总线704,处理器701可以访问存储器702，还可以利用通信接口703与其它计算机设备或者终端进行数据交互。

在本申请中，计算机设备700执行存储器702中的计算机指令，使得计算机设备700实现本申请提供的执行计划的处理方法，或者使得计算机设备700部署数据库系统。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器，上述指令可由服务器的处理器执行以完成本申请各个实施例所示的执行计划的处理方法。例如，该非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

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

在本申请中，术语“第一”、“第二”和“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性。术语“至少一个”表示1个或多个，术语“多个”指两个或两个以上，除非另有明确的限定。A参考B，指的是A与B相同或者A为B的简单变形。

需要说明的是：上述实施例提供的数据库系统在执行该执行计划的处理方法时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的数据库系统与执行计划的处理方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (32)

1.一种执行计划的处理方法，其特征在于，所述方法包括：

执行结构化查询语言SQL语句的第一执行计划；

在所述SQL语句的第一执行计划的性能劣化时，获取所述SQL语句的第二执行计划；

执行所述第二执行计划来替换对所述第一执行计划的执行。

2.根据权利要求1所述的方法，其特征在于，所述第二执行计划与所述第一执行计划不同。

3.根据权利要求2所述的方法，其特征在于，所述第二执行计划的性能优于所述第一执行计划的性能。

4.根据权利要求1至3任一所述的方法，其特征在于，所述获取所述SQL语句的第二执行计划，包括：

获取所述SQL语句的历史执行计划；

当所述历史执行计划的性能优于所述第一执行计划的性能时，将所述历史执行计划作为所述第二执行计划。

5.根据权利要求1至3任一所述的方法，其特征在于，所述获取所述SQL语句的第二执行计划，包括：

生成所述SQL语句的第二执行计划。

6.根据权利要求5所述的方法，其特征在于，生成所述SQL语句的第二执行计划所占用的计算资源大于生成所述SQL语句的第一执行计划所占用的计算资源，和/或，生成所述SQL语句的第二执行计划的时长大于生成所述SQL语句的第一执行计划的时长。

7.根据权利要求1至6任一所述的方法，其特征在于，所述方法还包括：

在所述SQL语句的第一执行计划的性能劣化时，发送告警指示信息。

8.根据权利要求1至7任一所述的方法，其特征在于，所述获取所述SQL语句的第二执行计划，包括：

在接收到执行计划优化指令后，获取所述SQL语句的第二执行计划。

9.根据权利要求1至8任一所述的方法，其特征在于，所述方法还包括：

在新版本的执行计划的性能优于所述第二执行计划的性能时，执行所述新版本的执行计划来替换对所述第二执行计划的执行。

10.根据权利要求1至9任一所述的方法，其特征在于，所述方法还包括：

当所述第一执行计划的运行指标出现异常时，确定所述SQL语句的第一执行计划的性能劣化。

11.根据权利要求10所述的方法，其特征在于，所述第一执行计划的运行指标包括以下的一种或多种：

所述第一执行计划的输入输出IO指标、时延、错误信息、执行次数和处理时长。

12.根据权利要求10或11所述的方法，其特征在于，所述方法还包括：

对于所述第一执行计划的运行指标中的每个运行指标，当所述运行指标对应的运行指标数据组指示的性能低于所述运行指标对应的所述SQL语句的历史运行指标数据组指示的性能，确定所述运行指标出现异常；

和/或，对于所述第一执行计划的运行指标中的每个运行指标，将所述运行指标对应的运行指标数据组输入第一人工智能模型，当所述第一人工智能模型输出指示所述运行指标异常的指示信息，确定所述运行指标出现异常。

13.根据权利要求12所述的方法，其特征在于，所述方法还包括：

对于所述第一执行计划的运行指标中的每个运行指标，当所述运行指标对应的运行指标数据组的性能曲线与所述运行指标的性能基线不匹配时，确定所述运行指标对应的运行指标数据组指示的性能低于所述历史运行指标数据组指示的性能，所述运行指标的性能基线基于所述历史运行指标数据组确定。

14.根据权利要求13所述的方法，其特征在于，所述方法还包括：

基于第二人工智能模型以及所述历史运行指标数据组，生成所述运行指标的性能基线。

15.一种执行计划的处理方法，其特征在于，所述方法包括：

执行结构化查询语言SQL语句的第一执行计划；

获取所述SQL语句的新版本的第二执行计划；

在所述第二执行计划的性能优于所述第一执行计划的性能时，执行所述第二执行计划来替换对所述第一执行计划的执行。

16.一种数据库系统，其特征在于，所述数据库系统包括：

执行模块，用于执行结构化查询语言SQL语句的第一执行计划；

获取模块，用于在所述SQL语句的第一执行计划的性能劣化时，获取所述SQL语句的第二执行计划；

所述执行模块还用于执行所述第二执行计划来替换对所述第一执行计划的执行。

17.根据权利要求16所述的数据库系统，其特征在于，所述第二执行计划与所述第一执行计划不同。

18.根据权利要求17所述的数据库系统，其特征在于，所述第二执行计划的性能优于所述第一执行计划的性能。

19.根据权利要求16至18任一所述的数据库系统，其特征在于，所述获取模块，用于：

获取所述SQL语句的历史执行计划；

当所述历史执行计划的性能优于所述第一执行计划的性能时，将所述历史执行计划作为所述第二执行计划。

20.根据权利要求16至18任一所述的数据库系统，其特征在于，所述获取模块，用于：

生成所述SQL语句的第二执行计划。

21.根据权利要求20所述的数据库系统，其特征在于，生成所述SQL语句的第二执行计划所占用的计算资源大于生成所述SQL语句的第一执行计划所占用的计算资源，和/或，生成所述SQL语句的第二执行计划的时长大于生成所述SQL语句的第一执行计划的时长。

22.根据权利要求16至21任一所述的数据库系统，其特征在于，所述数据库系统还包括：

告警模块，用于在所述SQL语句的第一执行计划的性能劣化时，发送告警指示信息。

23.根据权利要求16至22任一所述的数据库系统，其特征在于，所述获取模块，用于：

在接收到执行计划优化指令后，获取所述SQL语句的第二执行计划。

24.根据权利要求16至23任一所述的数据库系统，其特征在于，所述执行模块，还用于：

在新版本的执行计划的性能优于所述第二执行计划的性能时，执行所述新版本的执行计划来替换对所述第二执行计划的执行。

25.根据权利要求16至24任一所述的数据库系统，其特征在于，所述数据库系统还包括：

确定模块，用于当所述第一执行计划的运行指标出现异常时，确定所述SQL语句的第一执行计划的性能劣化。

26.根据权利要求25所述的数据库系统，其特征在于，所述第一执行计划的运行指标包括以下的一种或多种：

所述第一执行计划的输入输出IO指标、时延、错误信息、执行次数和处理时长。

27.根据权利要求25或26所述的数据库系统，其特征在于，所述确定模块，用于：

对于所述第一执行计划的运行指标中的每个运行指标，当所述运行指标对应的运行指标数据组指示的性能低于所述运行指标对应的所述SQL语句的历史运行指标数据组指示的性能，确定所述运行指标出现异常；

和/或，对于所述第一执行计划的运行指标中的每个运行指标，将所述运行指标对应的运行指标数据组输入第一人工智能模型，当所述第一人工智能模型输出指示所述运行指标异常的指示信息，确定所述运行指标出现异常。

28.根据权利要求27所述的数据库系统，其特征在于，所述确定模块，用于：

对于所述第一执行计划的运行指标中的每个运行指标，当所述运行指标对应的运行指标数据组的性能曲线与所述运行指标的性能基线不匹配时，确定所述运行指标对应的运行指标数据组指示的性能低于所述历史运行指标数据组指示的性能，所述运行指标的性能基线基于所述历史运行指标数据组确定。

29.根据权利要求28所述的数据库系统，其特征在于，所述数据库系统还包括：

基线生成模块，用于基于第二人工智能模型以及所述历史运行指标数据组，生成所述运行指标的性能基线。

30.一种数据库系统，其特征在于，所述数据库系统包括：

执行模块，用于执行结构化查询语言SQL语句的第一执行计划；

获取模块，用于获取所述SQL语句的新版本的第二执行计划；

所述执行模块还用于在所述第二执行计划的性能优于所述第一执行计划的性能时，执行所述第二执行计划来替换对所述第一执行计划的执行。

31.一种计算机设备，其特征在于，包括：

处理器和存储器；

所述存储器，用于存储计算机指令；

所述处理器，用于执行所述存储器存储的计算机指令，使得所述计算机设备执行权利要求1至14任一所述的执行计划的处理方法，或者，执行权利要求15所述的执行计划的处理方法。

32.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质包括计算机指令，所述计算机指令指示计算机设备执行权利要求1至14任一所述的执行计划的处理方法，或者，执行权利要求15所述的执行计划的处理方法。

Images