CN114610588A

CN114610588A - 一种数据库性能分析方法、装置、电子设备和存储介质

Info

Publication number: CN114610588A
Application number: CN202210195836.6A
Authority: CN
Inventors: 熊亮春; 李宇; 潘安群; 雷海林
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd; Tencent Cloud Computing Beijing Co Ltd
Priority date: 2022-03-01
Filing date: 2022-03-01
Publication date: 2022-06-10

Abstract

本申请涉及数据处理技术领域，尤其涉及一种数据库性能分析方法、装置、电子设备和存储介质，用以提高数据库性能分析的全面性和准确性。其中，方法包括：获取数据库中各处理节点的资源处理描述信息；分别对各处理节点各自的资源处理描述信息进行关键信息提取，并基于提取结果，获得具有预设日志格式的目标日志信息；基于目标日志信息对数据库进行性能分析，获得性能分析结果；基于性能分析结果，对数据库进行运行情况预测。由于本申请通过获取各处理节点的资源处理描述信息，并进行关键信息提取，构建不同处理级别对应的日志信息，将本申请部署于数据库上，能够自动化的对数据库进行更细粒度的检测与分析，提高数据库性能分析的全面性和准确性。

Description

一种数据库性能分析方法、装置、电子设备和存储介质

技术领域

本申请涉及数据处理技术领域，尤其涉及一种数据库性能分析方法、装置、电子设备和存储介质。

背景技术

数据库系统在计算机领域属于基础架构之一，随着业务的发展和数据库的广泛应用，在实际应用中发挥的作用也越来越大。其中，通过数据库性能分析组件，对于相对应的对象在运行期间的数据进行采集与分析，能够让数据库使用方直观的了解到整个数据库运行的健康状况，以保证数据库的正常运行。

相关技术中，对于数据库运行的性能问题分析的实现方法通常是：在数据库各节点进程的同一个机器上面部署一个代理(Agent)组件，如图1所示，利用数据库节点提供的指标上报接口，周期性的上报对应的指标到Agent，然后由Agent将这些运行时信息上报到性能检测与分析模块来集中处理。

但是，上述设置Agent组件的方式，在新增检测类型时，需要对数据库模块实现路径进行检测与打桩，进而干扰数据库本身的实现逻辑；并且，该方式的功能扩展能力差，无法进行更细粒度的分析，因而对数据库的某些方面的性能无法进行有效分析，导致性能分析结果不过完善和准确。因此，如何对数据库的性能问题进行更细粒度的检测与分析是目前亟待解决的问题。

发明内容

本申请实施例提供一种数据库性能分析方法、装置、电子设备和存储介质，用以提高数据库性能分析的全面性和准确性。

本申请实施例提供的第一种数据库性能分析方法，包括：

获取数据库中各处理节点的资源处理描述信息，每个处理节点具有至少一种数据处理能力；

分别对所述各处理节点各自的资源处理描述信息进行关键信息提取，并基于提取结果，获得具有预设日志格式的目标日志信息，所述预设日志格式包括：不同处理级别下的日志信息表示规则；

基于所述目标日志信息对所述数据库进行性能分析，获得性能分析结果；

基于所述性能分析结果，对所述数据库进行运行情况预测。

本申请实施例提供的第一种数据库性能分析装置，包括：

获取单元，获取数据库中各处理节点的资源处理描述信息，每个处理节点具有至少一种数据处理能力；

提取单元，分别对所述各处理节点各自的资源处理描述信息进行关键信息提取，并基于提取结果，获得具有预设日志格式的目标日志信息，所述预设日志格式包括：不同处理级别下的日志信息表示规则；

分析单元，基于所述目标日志信息对所述数据库进行性能分析，获得性能分析结果；

预测单元，基于所述性能分析结果，对所述数据库进行运行情况预测。

可选的，所述不同的处理级别至少包括：记录处理级别和节点处理级别；每个处理节点为计算节点或存储节点；所述分析单元具体用于：

基于所述目标日志信息中与节点处理级别和记录处理级别相关的各个数据处理时间信息，获得记录处理时耗信息，所述记录处理时耗信息包括：计算节点的数据处理时长、所述计算节点的数据发送时长、存储节点的数据读取时长、所述存储节点的数据返回时长中的至少一种；

基于所述记录处理时耗信息，对所述数据库进行性能分析。

可选的，所述记录处理时耗信息包括存储节点的数据读取时长；在所述基于所述记录处理时耗信息，对所述数据库进行性能分析之前，所述分析单元还用于：

基于所述计算节点与所述存储节点之间的时钟时间差，对所述存储节点针对目标数据的数据接收时间进行调整，并基于调整后的数据接收时间，更新所述存储节点的数据读取时长，所述目标数据为所述计算时间与所述存储节点之间传输的数据。

可选的，所述记录处理时耗信息包括存储节点的数据返回时长；在所述基于所述记录处理时耗信息，对所述数据库进行性能分析之前，所述分析单元还用于：

基于所述计算节点与所述存储节点之间的时钟时间差，对所述计算节点针对目标数据的数据返回接收时间进行调整，基于调整后的数据返回接收时间，更新所述存储节点的数据返回时长。

可选的，所述不同的处理级别至少包括：语句处理级别；所述装置还包括执行单元，用于：

基于预设的查询语句匹配规则，获得所述数据库中一定时间范围内已执行的多个相同的查询语句；

基于所述目标日志信息中与语句处理级别相关的各个数据处理时间信息，将所述各个查询语句按照开始执行时间划分至不同时间窗，并获得所述查询语句在不同时间窗周期执行的时间规律；

基于确定的周期执行的时间规律，在下一时间窗内自动执行所述查询语句。

可选的，所述目标日志信息包括：各个资源在第一预设时间段内的第一访问量；所述分析单元具体用于：

将所述各个资源中，第一访问量高于预设阈值中的至少一个资源，作为热点资源，并为各个热点资源创建各自对应的多个副本。

可选的，所述分析单元还用于：

获取所述各个热点资源在第二预设时间段内的第二访问量，其中，所述第二预设时间段在所述第一预设时间段之后；

将所述各个热点资源中，第二访问量低于所述预设阈值的至少一个热点关键资源，各自对应的多个副本分别进行合并。

可选的，所述不同处理级别至少包括：语句处理级别；所述目标日志信息包括：一个查询语句相关的不同查询方式各自对应的执行时长；所述装置还包括确定单元，用于：

对于一个查询语句，基于所述一个查询语句相关的不同查询方式各自对应的执行时长，确定所述一个查询语句的目标查询方式，所述一个查询语句对应的执行时长大于预设时长；

基于所述目标查询方式执行所述一个查询语句。

可选的，所述不同处理级别至少包括节点处理级别；所述分析单元具体用于：

基于所述目标日志信息中与节点处理级别相关的各处理节点的存储数据量，以及所述数据库的总存储空间，对所述数据库进行分析，获得所述性能分析结果。

可选的，所述预测单元具体用于：

若所述性能分析结果表征所述存储数据量占总存储空间的比值高于预设上限阈值，则确定需要增加所述数据库存储节点的数量；

若所述性能分析结果为所述存储数据量占总存储空间的比值低于预设下限阈值，则确定需要减少所述数据库存储节点的数量。

本申请实施例提供的一种电子设备，包括处理器和存储器，其中，所述存储器存储有计算机程序，当所述计算机程序被所述处理器执行时，使得所述处理器执行上述任意一种数据库性能分析方法的步骤。

本申请实施例提供一种计算机可读存储介质，其包括计算机程序，当所述程序代码在电子设备上运行时，所述计算机程序用于使所述电子设备执行上述任意一种数据库性能分析方法的步骤。

本申请实施例提供一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序存储在计算机可读存储介质中；当电子设备的处理器从计算机可读存储介质读取所述计算机程序时，所述处理器执行所述计算机程序，使得所述电子设备执行上述任意一种数据库性能分析方法的步骤。

本申请有益效果如下：

本申请实施例提供的数据库性能分析方法、装置、电子设备和存储介质，由于本申请通过获取数据库中各处理节点的资源处理描述信息，并分别对各处理节点各自的资源处理描述信息进行关键信息提取，并基于提取结果，获得具有预设日志格式的目标日志信息，能够基于数据库相关的各节点完成对数据库运行期间的数据采集，不会对干扰数据库自身的实现逻辑；进一步的，基于目标日志信息对数据库进行性能分析，获得性能分析结果，并基于性能分析结果，对数据库进行运行情况预测，能够在不同处理级别下对数据库进行更细粒度的性能分析，提高数据库性能分析的全面性和准确性，并能够基于数据库历史运行情况进行数据库运行情况预测。

本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请而了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为相关技术中的一种数据库性能的检测与分析方案的模型示意图；

图2为本申请实施例中的一种应用场景的一个可选的示意图；

图3为本申请实施例中的一种数据库性能分析方法的实施流程图；

图4为本申请实施例中的一种数据库性能分析方法的模型示意图；

图5为本申请实施例中的一种关键信息提取的方法的模块示意图；

图6为本申请实施例中的一种二阶段提交的事务处理时序图；

图7为本申请实施例中的一种时钟误差校正方法的结构示意图；

图8为本申请实施例中的一种数据库性能分析装置的组成结构示意图；

图9为应用本申请实施例的一种电子设备的一个硬件组成结构示意图；

图10为应用本申请实施例的另一种电子设备的一个硬件组成结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请技术方案的一部分实施例，而不是全部的实施例。基于本申请文件中记载的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请技术方案保护的范围。

下面对本申请实施例中涉及的部分概念进行介绍。

结构化查询语言(Structured Query Language，SQL)：是一种特殊目的的编程语言，是一种数据库查询和程序设计语言，用于存取数据以及查询、更新和管理关系数据库系统。具有完全不同底层结构的不同数据库系统,可以使用相同的结构化查询语言作为数据输入与管理的接口。由于结构化查询语言语句可以嵌套，这使它具有极大的灵活性和强大的功能。

数据库性能分析组件：主要用于采集、分析数据库在运行过程中，主要对象的运行情况，例如数据库主要动态执行对象有事务执行情况、SQL语句执行情况、语句或事务执行过程中的锁持有情况、以及其他数据库运行过程中对于资源使用的情况。通过数据库性能分析组件对相应的对象运行期间的数据采集与分析，能够让数据库用户直观的了解整个数据库运行的健康状况，并且性能分析组件也可以通过对数据库管理员(DBA)采取措施进行分析学习后，在后续遇到相同情况时能够自动执行相应的操作。

计算引擎节点(SQL Engine)：也即本申请中的计算节点，计算节点负责SQL语句解析、查询优化，以及事务的并发控制等等，主要完成SQL层计算功能。

存储引擎节点(TD Store)：也即本申请中的存储节点，主要完成事务的存储功能，包括支持数据块存储、备份等作用。

集群管理节点(MC)：管理整个集群必须的信息，例如，集中事务id分配模块、集中锁管理模块，其中，集中式模块会成为分布式数据库的水平扩展的瓶颈，需要尽可能的减少集中式管理模块需要处理的事项，以增加整个分布式数据库的水平扩展能力。

二阶段提交：是指在计算机网络以及数据库领域内，为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法，主要算法思路为：参与者将操作成败通知协调者，再由协调者根据所有参与者反馈情报决定各参与者是提交操作还是终止操作。

本申请实施例涉及云技术领域，通过云技术中的云存储技术实现数据库的构建。具体地，本申请实施例通过对相关的日志信息进行格式扩展，将数据库运行情况记录下来，并实现对数据库性能分析和预测。

云技术(Cloud technology)基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，只能通过云计算来实现。

云存储(cloud storage)是在云计算概念上延伸和发展出来的一个新的概念，分布式云存储系统(以下简称存储系统)是指通过集群应用、网格技术以及分布存储文件系统等功能，将网络中大量各种不同类型的存储设备(存储设备也称之为存储节点)通过应用软件或应用接口集合起来协同工作，共同对外提供数据存储和业务访问功能的一个存储系统。

数据库(Database)，简而言之可视为电子化的文件柜——存储电子文件的处所，用户可以对文件中的数据进行新增、查询、更新、删除等操作。所谓“数据库”是以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。

数据库管理系统(Database Management System，DBMS)是为管理数据库而设计的电脑软件系统，一般具有存储、截取、安全保障、备份等基础功能。数据库管理系统可以依据它所支持的数据库模型来作分类，例如关系式、XML(Extensible Markup Language，即可扩展标记语言)；或依据所支持的计算机类型来作分类，例如服务器群集、移动电话；或依据所用查询语言来作分类，例如SQL(结构化查询语言(Structured Query Language)、XQuery；或依据性能冲量重点来做分类，例如最大规模、最高运行速度；亦或其他的分类方式。不论使用哪种分类方式，一些DBMS能够跨类别，例如，同时支持多种查询语言。

下面对本申请实施例的设计思想进行简要介绍：

相关技术中，对于数据库运行的性能问题分析的实现方法通常是：在数据库各节点进程的同一个机器上面部署一个代理(Agent)组件，用来对于模块的运行进行检测与指标采集，如图1所示，利用数据库节点提供的指标上报接口，周期性的上报对应的指标到Agent，然后由Agent将这些运行时信息上报到性能检测与分析模块来集中处理，实现对于数据库的性能检测与分析模块。

但是，上述设置Agent组件的方式，需要数据库内核上报的数据来分析，并且在新增检测类型时，需要对数据库模块实现路径进行检测与打桩，进而干扰数据库本身的实现逻辑，功能扩展能力差；并且，目前分布式数据库场景下的，数据的处理往往要经过多个节点的处理，以事务、SQL语句级别甚至到记录级别的数据流转性能的分析能力的缺失，在分析数据库性能问题的时候，对于按照事务，SQL语句级别的分析能力不足，同时也不容易将SQL语句，事务的执行问题，进行更细粒度的分析，因而对数据库的某些方面的性能无法进行有效分析，导致性能分析结果不过完善和准确。

有鉴于此，本申请实施例提供了一种数据库性能分析方法、装置、电子设备和存储介质，由于本申请通过获取数据库中各处理节点的资源处理描述信息，并分别对各处理节点各自的资源处理描述信息进行关键信息提取，并基于提取结果，获得具有预设日志格式的目标日志信息，能够基于数据库相关的各节点完成对数据库运行期间的数据采集，不会对干扰数据库自身的实现逻辑；进一步的，基于目标日志信息对数据库进行性能分析，获得性能分析结果，并基于性能分析结果，对数据库进行运行情况预测，能够在不同处理级别下对数据库进行更细粒度的性能分析，提高数据库性能分析的全面性和准确性，并能够基于数据库历史运行情况进行数据库运行情况预测。

以下结合说明书附图对本申请的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本申请，并不用于限定本申请，并且在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

如图2所示，其为本申请实施例的应用场景示意图。该应用场景图中包括两个终端设备210和一个服务器220。

在本申请实施例中，终端设备210包括但不限于手机、平板电脑、笔记本电脑、台式电脑、电子书阅读器、智能语音交互设备、智能家电、车载终端等设备；终端设备上可以安装有数据库性能分析相关的客户端，该客户端可以是软件(例如浏览器、分析软件等)，也可以是网页、小程序等，服务器220则是与软件或是网页、小程序等相对应的后台服务器，或者是专门用于进行数据库性能分析的服务器，本申请不做具体限定。服务器220可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(Content Delivery Network，内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器。

需要说明的是，本申请实施例中的数据库性能分析方法可以由电子设备执行，该电子设备可以为服务器220或者终端设备210，即，该方法可以由服务器220或者终端设备210单独执行，也可以由服务器220和终端设备210共同执行。比如由服务器220单独执行时，获取数据库中各处理节点的资源处理描述信息，并分别对各处理节点各自的资源处理描述信息进行关键信息提取，基于提取结果，获得具有预设日志格式的目标日志信息，然后基于目标日志信息对数据库进行性能分析，获得性能分析结果，最后基于性能分析结果，对数据库进行运行情况预测。

在一种可选的实施方式中，终端设备210与服务器220之间可以通过通信网络进行通信。

在一种可选的实施方式中，通信网络是有线网络或无线网络。

需要说明的是，图2所示只是举例说明，实际上终端设备和服务器的数量不受限制，在本申请实施例中不做具体限定。

本申请实施例中，当服务器的数量为多个时，多个服务器可组成为一区块链，而服务器为区块链上的节点；如本申请实施例所公开的数据库性能分析方法，其中所涉及的各处理节点的资源处理描述信息可保存于区块链上。

此外，本申请实施例可应用于各种场景，不仅包括数据库场景，还包括但不限于云技术、人工智能、智慧交通、辅助驾驶等场景，当本申请实施例应用于智慧交通场景时，能够对数据库中存储的道路情况进行提取、分析，为用户提供路况预测。

下面结合上述描述的应用场景，参考附图来描述本申请示例性实施方式提供的数据库性能分析方法，需要注意的是，上述应用场景仅是为了便于理解本申请的精神和原理而示出，本申请的实施方式在此方面不受任何限制。

参阅图3所示，为本申请实施例提供的一种数据库性能分析方法的实施流程图，应用于服务器，该方法的具体实施流程如下：

S31：服务器获取数据库中各处理节点的资源处理描述信息；

其中，每个处理节点具有至少一种数据处理能力，例如，TDSQL分布式数据库的主要处理节点包括计算节点、存储节点和集群管理节点，资源处理描述信息表示数据库运行时的关键资源运行情况，包括但不限于锁的占用、热点数据访问等情况。

S32：服务器分别对各处理节点各自的资源处理描述信息进行关键信息提取，并基于提取结果，获得具有预设日志格式的目标日志信息；

其中，预设日志格式包括：不同处理级别下的日志信息表示规则，不同的处理级别可以是集群、机器、数据库实例、数据库不同节点、事务、查询语句、记录处理等。

S33：服务器基于目标日志信息对数据库进行性能分析，获得性能分析结果；

S34：服务器基于性能分析结果，对数据库进行运行情况预测。

在本申请实施例中，通过获取数据库中各处理节点的资源处理描述信息，并分别对各处理节点各自的资源处理描述信息进行关键信息提取，并基于提取结果，获得具有预设日志格式的目标日志信息，能够基于数据库相关的各节点完成对数据库运行期间的数据采集，不会对干扰数据库自身的实现逻辑；进一步的，基于目标日志信息对数据库进行性能分析，获得性能分析结果，并基于性能分析结果，对数据库进行运行情况预测，能够在不同处理级别下对数据库进行更细粒度的性能分析，提高数据库性能分析的全面性和准确性，并能够基于数据库历史运行情况进行数据库运行情况预测。

参阅图4所示，其为本申请实施例中的一种数据库性能分析方法的模型示意图，通过增加了分布式数据库或数据库运行期间的事务级或者语句级的运行时信息，能够和相关的操作系统已经数据库上报的运行状态信息有机整合起来，形成了一个自动驾驶的数据库运行态管理方案，实现简单且很容易与相关的数据库运维检测和性能检测模块集成。下面结合图4对本申请中的数据库性能分析方法进行具体介绍：

基于日志汇总模块：每个节点上模块进程对应的Agent不断的采集的日志，并按照一定的采集周期将收集到的日志发送至日志汇总模块，通过日志汇总模块，按照时间顺序将日志信息汇总排序，供后续处理；

语句、事务级时耗分析模型：首先基于日志汇总模块汇总后的日志信息，按照如图5所示的流程，进行顺序处理，提取关键信息，获得目标日志信息，

1.遇到一条开始事务日志，创建一个事务对象，并以事务id为标示；

2.遇到一条开始语句日志，创建一个语句对象，并以事务id，语句id作为联合标示，并将语句对象与事务对象建立关联方便后续计算；

3.遇到语句处理的日志，创建一个记录处理对象，以事务id，语句id，key作为联合表示，并与语句对象关联，建立联系；

4.当处理到下一条语句的开始语句日志时，上一个语句对象创建完成，保存在内存中供后续分析；

5.当遇到提交(commit)/回滚(rollback)语句，那么事务对象创建完成，保存在内存中供后续分析；

在一种可选的实施方式中，目标日志信息如下所示：

开始事务日志：【标签】【事务id】【节点id】【开始时间】

开始一条语句：【标签】【事务id】【节点id】【语句_id】【开始时间】

增/删/改/读/取一条记录：

主键记录：【标签】【事务id】【节点id】【主键key】【开始时间】

主键记录网络发送时间：

【标签】【事务id】【节点id】【主键键值key】【发送时间】【网络包大小】

主键记录网络接收时间：

【标签】【事务id】【节点id】【主键key】【接收时间】【网络包大小】

二级索引记录：

【标签】【事务id】【节点id】【索引键值index key】【主键key】【开始时间】

锁申请时间：

【标签】【事务id】【节点id】【锁类型】{【表】|【数据页面】【主键key】|【index key】}【发送时间】

锁授予/超时时间：

【标签】【事务id】【节点id】【锁类型】{【表】|【数据页面】【主键key】|【index key】}【授予时间】|【失败时间】

提交/回滚事务：

【标签】【事务id】【节点id】【2PC-Prepare准备阶段】【开始时间】

【标签】【事务id】【节点id】【2PC-Commit提交阶段】【开始时间】

其中，事务id：用来表明哪些信息属于一个事务，通常一个事务第一条日志是开始事务日志，最后一个是提交或回滚日志，并且两阶段事务也需要记录提交的准备阶段(prepare)的时间和提交阶段的耗时；

节点id：用于唯一表明当前记录来自哪个节点，例如TDSQL分布式数据库一般都有计算节点，存储引擎节点，管理节点等，通过将不同节点传输过来的信息利用语句id，事务id联系起来，则可以利用事务这个数据库操作的重要管理单元知道更为有用的数据库实时运行的情况；

语句id：用于区分不同作用的语句，通过语句id将语句在运行时所需要的资源，按照表级，数据页面(管理一组记录，用来提高数据的读写效率)，记录级一一对应能够更加清楚反映详细的数据库运行时的详细信息；

对于事务中记录的操作，包括增/删/改/查等操作，本申请统一使用上面的主键记录格式和二级索引记录格式。

进而，基于目标日志信息，可以进行语句、事务处理级别对事务处理耗时进行详细分析。

在一种可选的实施方式中，所述不同的处理级别至少包括：记录处理级别和节点处理级别；每个处理节点为计算节点或存储节点；基于如下方式进行数据库性能分析：

首先，基于目标日志信息中与节点处理级别和记录处理级别相关的各个数据处理时间信息，获得记录处理时耗信息，记录处理时耗信息包括：计算节点的数据处理时长、计算节点的数据发送时长、存储节点的数据读取时长、存储节点的数据返回时长中的至少一种；然后，基于记录处理时耗信息，对数据库进行性能分析。

需要说明的是，本申请实施例将一条记录处理时耗信息划分为以上四部分进行说明，实际上可以按照其他方式划分，得到更详细的记录处理时间分段信息，在此不做具体限定。

如图6所示，其为二阶段提交的事务处理时序图，下面以一条获取(GET)类型的远程过程消息(Remote Procedure Call，RPC)的传输过程为例，介绍如何获取一条记录处理的详细信息，把一条记录的耗时可以分为以下四部分：

(1)计算节点本地处理时间(即计算节点的数据处理时长)：

1.第一条记录：从初始化语句完毕开始，到发出一条GET消息网络请求的时间差；

2.其他记录：从接收到上一条记录，到返回给上层计算算子的时间为本条记录的扫描处理时间；

3.其他部分的处理时间：传统数据库都会有统计，直接利用单模块收集生产相应的日志信息即可；

(2)计算节点数据操作发送命令网络时间(即计算节点的数据发送时长)：

这部分时间由存储节点接收到命令的时间减去计算节点发送命令时间即可；

(3)存储节点读取记录时间(即存储节点的数据读取时长)：

1.细粒度，这块由存储节点通过对应的日志给出不同阶段的时间，输出更多存储节点内部处理记录的关键时间段；

2.粗粒度，存储节点接收到计算节点发送的数据命令时间减去存储节点返回数据消息的发送时间；

(4)存储节点返回数据网络时间(即存储节点的数据返回时长)：

这部分由存储节点返回数据消息发送时间减去计算节点接收到返回数据消息的时间。

具体实施中，可以根据如下程序创建t1、t2、t3三个表格：

CREATE TABLE t1(创建表t1c1 INTEGER DEFAULT NULL，列c1c2 INTEGERDEFAULT NULL列c2)；

CREATE TABLE t2(创建表t2c1 INTEGER DEFAULT NULL，列c1c2 INTEGERDEFAULT NULL列c2)；

CREATE TABLE t3(创建表t3pk INTEGER NOT NULL PRIMARY KEY，主键pkiINTEGER DEFAULT NULL列i)；

然后基于如下程序进行数据查询，能够获得数据查询过程中各节点耗费时间：

mysql>EXPLAIN ANALYZE(查询分析)SELECT*FROM t1 JOIN t2 ON(t1.c1＝t2.c2)\G

EXPLAIN:—>Inner hash join(t2.c2＝t1.c1)(cost＝4.70耗费时间rows＝6行数)(actual time＝0.032(最短时间)..0.035(最长时间)rows＝6loops＝1循环次数)

->Table scan on t2(扫描表t2)(cost＝0.06rows＝6)(actual time＝0.003..0.005rows＝6loops＝1)

—>Hash哈希值

—>Table scan on t1(扫描表t1)(cost＝0.85时间rows＝6行)

(actual local time实际本地处理时间＝0.018..0.022

net send time网络发送时间＝0.014..0.025

remote handler time远端处理时间＝0.03..0.06

net recv time rows网络接收时间＝0.021..0.033loops＝1)

在本申请实施例中，同时可以扩展explain analyze的展示粒度，将原来处理一条记录的时间分为多段，让用户更容易了解那部分时间占比更多。上述以TDSQL存算分离架构为例一条记录的扫描被分为：1)计算节点处理时间；2)计算节点向存储节点请求数据的网络时间；3)存储节点获取数据时间；4)存储节点返回数据的网络时间。

从图6上也可以看到，事务的提交在分布式数据库中有时候也会需要明显可感知到的时间，这部分也许要被记录分析，通常上述不同机器间会有时钟的不一致，即使采取NTP(Network Time Protocol，网络时间协议)，也会带来毫秒级误差，对于记录级的处理时耗是不可接受的。

在一种可选的实施方式中，记录处理时耗信息包括存储节点的数据读取时长；在基于记录处理时耗信息，对数据库进行性能分析之前，可以通过如下方式对数据读取时长进行校正：

基于计算节点与存储节点之间的时钟时间差，对存储节点针对目标数据的数据接收时间进行调整，并基于调整后的数据接收时间，更新存储节点的数据读取时长。

其中，目标数据为计算时间与存储节点之间传输的数据。

在一种可选的实施方式中，记录处理时耗信息包括存储节点的数据返回时长；在基于记录处理时耗信息，对数据库进行性能分析之前，可以通过如下方式对数据返回时长进行校正：

基于计算节点与存储节点之间的时钟时间差，对计算节点针对目标数据的数据返回接收时间进行调整，基于调整后的数据返回接收时间，更新存储节点的数据返回时长。

具体实施中，可以采取如图7所示的算法来矫正不同节点间的时钟误差，其中，T1为计算节点发送数据时间，T2为存储节点接收数据时间(即数据接收时间)，T3为存储节点发送数据时间，T4为计算节点接收数据时间(即数据返回接收时间)，d1表示从计算节点发送到存储节点所需的网络时间，d2表示从存储节点发送到计算节点所需的网络时间，t表示计算节点和存储节点之间的时间差，则存储节点接收数据时间T2＝T1+t+d1，计算节点接收数据时间T4＝T3-t+d2；另外，若t为正数，则说明存储节点的时间滞后，需要+|t|，若t为负数，则说明存储节点的时间超前，需要-|t|。假设d＝d1+d2，d1＝d2，则

d＝(T2-T1)+(T4-T3)。

因此，基于T1，T2，T3和T4，以及上述对时间进行校正的公式能够精确的每个阶段的网络时间开销。将数据库/分布式数据库比较关键的模块之间的网络时耗，细化到记录级的性能分析，同时通过时间窗能够将数据库内部，外部导致问题的情况联系起来进行全面的分析。

在本申请实施例中，当数据库产生性能问题，能够保留产生问题的数据库当时的运行时信息，例如慢查询，能够收集当时慢查询记录级别的处理统计信息，并进行分析处理；只需要通过扩展数据库节点原有的日志信息，或者新增对应的日志信息即可实现数据库节点运行实时情况的收集，供后续分析使用；可以很容易与相关方案融合，在迅速利用相关比较粗粒度对于数据库集群能力分析的同时，也能够集成以事务，SQL语句以及记录在不同节点中处理的时间来更详细，更为准确的反映数据库运行时的状态。

基于时间窗关联分析模型：本申请实施例中的性能分析模块是建立在日志流基础上，因此，本申请可以将事务、语句按照时间窗划分到不同的时间窗，来产生基于时间窗的数据库运行时性能时间窗，同时基于时间窗也可以将当前已经实现的对数据库运行时检测的数据融合起来，实现更多的自动驾驶操作。

在本申请实施例中，可以对分布式数据库的实时运行情况进行数据库关键对象运行时建模，然后基于多个时间窗对于用户使用数据库的业务特点进行分析，同时给出相应的优化措施，自动优化数据库的数据分布，索引使用等等，达到自动驾驶的目标。

基于时间周期的规律学习模块：

在一种可选的实施方式中，不同的处理级别至少包括：语句处理级别；

基于预设的查询语句匹配规则，获得数据库中一定时间范围内已执行的多个相同的查询语句；基于目标日志信息中与语句处理级别相关的各个数据处理时间信息，将各个查询语句按照开始执行时间划分至不同时间窗，并获得查询语句在不同时间窗周期执行的时间规律；基于确定的周期执行的时间规律，在下一时间窗内自动执行查询语句。

具体实施中，可以在语句格式化后计算语句的一个hash因子，通过比对hash因子确定是否是同一条语句，通常数据库开始执行一条语句的时候，都会打印一条start stmt的日志，代表语句开始，在本申请中也会找到这条语句作为查询语句开始时间。例如，获得的多个查询语句为导出考勤数据操作，将各个查询语句按照开始执行时间划分到不同的月份，可以获得用户在每个月1号早上9点会进行导出考勤数据操作，可以根据此规律在下个月的1号9点之前提前执行此查询语句，这样就可以节省用户在执行查询语句是所需要等待的时间。

在本申请实施例中，根据查询的语句的匹配规则，找出周期执行的报表，可以采取根据语句执行时间提前自动触发系统执行，并返回结果，减少查询等待时间，提高查询效率。此部分可以由基于时间周期的规律学习模块完成。

通过按照日志信息分析，更容易实现对于数据库整体性能的时间维度上的流式处理，更容易联系在同一时间窗内数据库中发生各种事件的关系。

自动驾驶优化模块：

在一种可选的实施方式中，不同处理级别至少包括：语句处理级别；目标日志信息包括：一个查询语句相关的不同查询方式各自对应的执行时长；可以通过以下方式优化查询语句的执行时间：

对于一个查询语句，基于一个查询语句相关的不同查询方式各自对应的执行时长，确定一个查询语句的目标查询方式，一个查询语句对应的执行时长大于预设时长；基于目标查询方式执行一个查询语句。

例如，对应于select*from t1 where A1>？这个简单语句为例，如果在a1列上有一个二级索引，那执行这条语句的时候根据用户传递给查询中A1>？中问号的具体值可以有如下两种情况：1)符合条件A1>10记录在表中占比较少，使用索引访问效率比较高；2)反之，符合条件的记录在表中占比较多则使用全表扫描效率会更高。

因此，本申请可以根据初始化由优化器给出一个查询计划，然后比对每次查询的执行，如果发生很大的执行时间不同，则对于不同情况逐步生成新的匹配的查询计划，最后使得用户的每次查询都能够以一个最优的计划执行。能够在事务与语句级别分析数据库各个模块资源的使用情况，通常事务与语句级的特点直接反映了用户业务的特点，因此这样的输入数据的分析更能够得到符合用户业务特点的优化建议。

在一种可选的实施方式中，不同处理级别至少包括节点处理级别；通过如下方式对数据库进行性能分析：

基于目标日志信息中与节点处理级别相关的各处理节点的存储数据量，以及数据库的总存储空间，对数据库进行分析，获得性能分析结果。

在本申请实施例中，各处理节点的存储数据量可以通过数据库内核查询自己节点，存储数据文件的大小来确定，然后可以通过日志的方式输出，可以很方便的基于数据库运行的历史规律采集分析的基础上，针对数据库进行自动驾驶级别的反馈操作。

在一种可选的实施方式中，若性能分析结果表征存储数据量占总存储空间的比值高于预设上限阈值，则确定需要增加数据库存储节点的数量；若性能分析结果为存储数据量占总存储空间的比值低于预设下限阈值，则确定需要减少数据库存储节点的数量。

具体地，通过对数据库存储节点，磁盘用量的分析，若确定需要增加数据库存储节点的数量即进行扩容，能够更加合理的将数据划分到不同节点，并根据用户数据增长的规律来分析需要增加多少个存储节点，部署在哪些IDC(Internet Data Center，互联网数据中心)，然后能够指导数据库以最优的方式来迁移数据；同样的，若确定需要减少存储节点的数量，即进行缩容，可以根据用户业务规律来更好的将相关数据迁移到最合适的节点。

需要说明的是，判断数据库需要是否需要扩容或缩容的方式，不限于本申请中的基于存储数据量占总空间的比值的方式，还可以是其他判断数据库存储容量的方式在此不做具体限定。

基于日志流式数据的并能够做到以事务，查询语句为单位的分析方式，可以让性能检测模块更容易的学习到数据库运行的业务特点，然后根据业务特点可以做到自动提供优化建议，并通过Agent反馈到相应的节点自适应调整。

在一种可选的实施方式中，将各个资源中，第一访问量高于预设阈值中的至少一个资源，作为热点资源，并为各个热点资源创建各自对应的多个副本。

在本申请实施例中，在某个时间窗，或者连续时间窗范围内，发现某一个资源(可以是记录，区域region，CPU，内存等等)的用户事务访问量很大，则认为该资源在那些时间段存在热点，某条记录，在某个时间窗内，被多个事务操作，达到一定阈值可以认为该记录是热点记录；同理，某个region在某一个时间段被多个事务访问，可以认为是热点region，则为热点资源创建多个副本。

例如，针对机票预订系统某个航班的余票记录，如果发现热点后自动在数据库中克隆多条同一航班的记录，将余票数按照一定的算法分到这些记录中，使得所有记录余票数总和与克隆前单条记录一致，某段时间某个数据成为热点资源，会导致性能下降，这样增加多个可读写副本可以降低同时写一条记录导致阻塞得情况的发生概率。

在一种可选的实施方式中，获取各个热点资源在第二预设时间段内的第二访问量，将各个热点资源中，第二访问量低于预设阈值的至少一个热点关键资源，各自对应的多个副本分别进行合并。

其中，第二预设时间段在第一预设时间段之后，待发现热点过去后，将每个热点记录对应的多个副本合并，能够节省存储空间占用。

通常数据库中锁的开销，也是造成数据库性能问题的一个重要因素，对于事务中，不同锁的请求，持有耗时的收集，可以保存记录级别锁使用的情况，通常数据库也提供死锁，或者所等待的视图，但是不会记录值部分信息，一旦运行时没能及时查询这部分信息，事后只能靠推测来判断是否存在死锁。

在本申请实施例中，可以通过目标日志信息里面关于锁申请的消息汇总分析出来是否当前分布式数据库系统中存在死锁。通过扩展分布式数据库日志的方式，能够将数据库运行时的关键资源运行情况记录下来，实时分析或者供发现问题的时候找到问题时间点，还原当时系统事务，语句执行情况。

在本申请实施例中，通过利用现有分布式数据库各模块现有的或者新增的日志，来完成对于数据库运行期间关键事件的采集，并汇总到数据库性能分析组件中统一分析，将数据库性能分析通过日志流转换为对于数据库运行过程中的流式监控，并可以灵活的在集群、机器、数据库实例、数据库不同节点、事务、查询语句、记录处理等不同级别进行数据库在某一时间窗下的运行情况进行分析，输出分析报告，并可以根据基于数据库运行的历史情况进行分析预测数据库在未来运行过程中可能会发生的情况，并自动采取相应措施来提升数据库平稳提供服务的能力和问题发生后的根因分析能力。

基于相同的发明构思，本申请实施例还提供一种数据库性能分析装置。如图8所示，其为数据库性能分析装置800的结构示意图，可以包括：

获取单元801，获取数据库中各处理节点的资源处理描述信息，每个处理节点具有至少一种数据处理能力；

提取单元802，分别对各处理节点各自的资源处理描述信息进行关键信息提取，并基于提取结果，获得具有预设日志格式的目标日志信息，预设日志格式包括：不同处理级别下的日志信息表示规则；

分析单元803，基于目标日志信息对数据库进行性能分析，获得性能分析结果；

预测单元804，基于性能分析结果，对数据库进行运行情况预测。

可选的，不同的处理级别至少包括：记录处理级别和节点处理级别；每个处理节点为计算节点或存储节点；分析单元803具体用于：

基于目标日志信息中与节点处理级别和记录处理级别相关的各个数据处理时间信息，获得记录处理时耗信息，记录处理时耗信息包括：计算节点的数据处理时长、计算节点的数据发送时长、存储节点的数据读取时长、存储节点的数据返回时长中的至少一种；

基于记录处理时耗信息，对数据库进行性能分析。

可选的，记录处理时耗信息包括存储节点的数据读取时长；在基于记录处理时耗信息，对数据库进行性能分析之前，分析单元803还用于：

基于计算节点与存储节点之间的时钟时间差，对存储节点针对目标数据的数据接收时间进行调整，并基于调整后的数据接收时间，更新存储节点的数据读取时长，目标数据为计算时间与存储节点之间传输的数据。

可选的，记录处理时耗信息包括存储节点的数据返回时长；在基于记录处理时耗信息，对数据库进行性能分析之前，分析单元803还用于：

可选的，不同的处理级别至少包括：语句处理级别；装置还包括执行单元805，用于：

基于预设的查询语句匹配规则，获得数据库中一定时间范围内已执行的多个相同的查询语句；

基于目标日志信息中与语句处理级别相关的各个数据处理时间信息，将各个查询语句按照开始执行时间划分至不同时间窗，并获得查询语句在不同时间窗周期执行的时间规律；

基于确定的周期执行的时间规律，在下一时间窗内自动执行查询语句。

可选的，目标日志信息包括：各个资源在第一预设时间段内的第一访问量；分析单元803具体用于：

将各个资源中，第一访问量高于预设阈值中的至少一个资源，作为热点资源，并为各个热点资源创建各自对应的多个副本。

可选的，分析单元803还用于：

获取各个热点资源在第二预设时间段内的第二访问量，其中，第二预设时间段在第一预设时间段之后；

将各个热点资源中，第二访问量低于预设阈值的至少一个热点关键资源，各自对应的多个副本分别进行合并。

可选的，不同处理级别至少包括：语句处理级别；目标日志信息包括：一个查询语句相关的不同查询方式各自对应的执行时长；装置还包括确定单元806，用于：

对于一个查询语句，基于一个查询语句相关的不同查询方式各自对应的执行时长，确定一个查询语句的目标查询方式，一个查询语句对应的执行时长大于预设时长；

基于目标查询方式执行一个查询语句。

可选的，不同处理级别至少包括节点处理级别；分析单元803具体用于：

可选的，预测单元804具体用于：

若性能分析结果表征存储数据量占总存储空间的比值高于预设上限阈值，则确定需要增加数据库存储节点的数量；

若性能分析结果为存储数据量占总存储空间的比值低于预设下限阈值，则确定需要减少数据库存储节点的数量。

为了描述的方便，以上各部分按照功能划分为各模块(或单元)分别描述。当然，在实施本申请时可以把各模块(或单元)的功能在同一个或多个软件或硬件中实现。

所属技术领域的技术人员能够理解，本申请的各个方面可以实现为系统、方法或程序产品。因此，本申请的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。

与上述方法实施例基于同一发明构思，本申请实施例中还提供了一种电子设备。在一种实施例中，该电子设备可以是服务器，如图2所示的服务器220。在该实施例中，电子设备的结构可以如图9所示，包括存储器901，通讯模块903以及一个或多个处理器902。

存储器901，用于存储处理器902执行的计算机程序。存储器901可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统，以及运行即时通讯功能所需的程序等；存储数据区可存储各种即时通讯信息和操作指令集等。

存储器901可以是易失性存储器(volatile memory)，例如随机存取存储器(random-access memory，RAM)；存储器901也可以是非易失性存储器(non-volatilememory)，例如只读存储器，快闪存储器(flash memory)，硬盘(hard disk drive，HDD)或固态硬盘(solid-state drive，SSD)；或者存储器901是能够用于携带或存储具有指令或数据结构形式的期望的计算机程序并能够由计算机存取的任何其他介质，但不限于此。存储器901可以是上述存储器的组合。

处理器902，可以包括一个或多个中央处理单元(central processing unit，CPU)或者为数字处理单元等等。处理器902，用于调用存储器901中存储的计算机程序时实现上述数据库性能分析方法。

通讯模块903用于与终端设备和其他服务器进行通信。

本申请实施例中不限定上述存储器901、通讯模块903和处理器902之间的具体连接介质。本申请实施例在图9中以存储器901和处理器902之间通过总线904连接，总线904在图9中以粗线描述，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。总线904可以分为地址总线、数据总线、控制总线等。为便于描述，图9中仅用一条粗线描述，但并不描述仅有一根总线或一种类型的总线。

存储器901中存储有计算机存储介质，计算机存储介质中存储有计算机可执行指令，计算机可执行指令用于实现本申请实施例的数据库性能分析方法。处理器902用于执行上述的数据库性能分析方法，如图3所示。

在另一种实施例中，电子设备也可以是其他电子设备，如图2所示的终端设备210。在该实施例中，电子设备的结构可以如图10所示，包括：通信组件1010、存储器1020、显示单元1030、摄像头1040、传感器1050、音频电路1060、蓝牙模块1070、处理器1080等部件。

通信组件1010用于与服务器进行通信。在一些实施例中，可以包括电路无线保真(Wireless Fidelity，WiFi)模块，WiFi模块属于短距离无线传输技术，电子设备通过WiFi模块可以帮助用户收发信息。

存储器1020可用于存储软件程序及数据。处理器1080通过运行存储在存储器1020的软件程序或数据，从而执行终端设备110的各种功能以及数据处理。存储器1020可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。存储器1020存储有使得终端设备210能运行的操作系统。本申请中存储器1020可以存储操作系统及各种应用程序，还可以存储执行本申请实施例数据库性能分析方法的代码。

显示单元1030还可用于显示由用户输入的信息或提供给用户的信息以及终端设备110的各种菜单的图形用户界面(graphical user interface，GUI)。具体地，显示单元1030可以包括设置在终端设备110正面的显示屏1032。其中，显示屏1032可以采用液晶显示器、发光二极管等形式来配置。显示单元1030可以用于显示本申请实施例中的数据库性能分析用户界面等。

显示单元1030还可用于接收输入的数字或字符信息，产生与终端设备110的用户设置以及功能控制有关的信号输入，具体地，显示单元1030可以包括设置在终端设备110正面的触摸屏1031，可收集用户在其上或附近的触摸操作，例如点击按钮，拖动滚动框等。

其中，触摸屏1031可以覆盖在显示屏1032之上，也可以将触摸屏1031与显示屏1032集成而实现终端设备110的输入和输出功能，集成后可以简称触摸显示屏。本申请中显示单元1030可以显示应用程序以及对应的操作步骤。

摄像头1040可用于捕获静态图像，用户可以将摄像头1040拍摄的图像通过应用发布评论。摄像头1040可以是一个，也可以是多个。物体通过镜头生成光学图像投射到感光元件。感光元件可以是电荷耦合器件(charge coupled device，CCD)或互补金属氧化物半导体(complementary metal-oxide-semiconductor，CMOS)光电晶体管。感光元件把光信号转换成电信号，之后将电信号传递给处理器1080转换成数字图像信号。

终端设备还可以包括至少一种传感器1050，比如加速度传感器1051、距离传感器1052、指纹传感器1053、温度传感器1054。终端设备还可配置有陀螺仪、气压计、湿度计、温度计、红外线传感器、光传感器、运动传感器等其他传感器。

音频电路1060、扬声器1061、传声器1062可提供用户与终端设备110之间的音频接口。音频电路1060可将接收到的音频数据转换后的电信号，传输到扬声器1061，由扬声器1061转换为声音信号输出。终端设备110还可配置音量按钮，用于调节声音信号的音量。另一方面，传声器1062将收集的声音信号转换为电信号，由音频电路1060接收后转换为音频数据，再将音频数据输出至通信组件1010以发送给比如另一终端设备210，或者将音频数据输出至存储器1020以便进一步处理。

蓝牙模块1070用于通过蓝牙协议来与其他具有蓝牙模块的蓝牙设备进行信息交互。例如，终端设备可以通过蓝牙模块1070与同样具备蓝牙模块的可穿戴电子设备(例如智能手表)建立蓝牙连接，从而进行数据交互。

处理器1080是终端设备的控制中心，利用各种接口和线路连接整个终端的各个部分，通过运行或执行存储在存储器1020内的软件程序，以及调用存储在存储器1020内的数据，执行终端设备的各种功能和处理数据。在一些实施例中，处理器1080可包括一个或多个处理单元；处理器1080还可以集成应用处理器和基带处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，基带处理器主要处理无线通信。可以理解的是，上述基带处理器也可以不集成到处理器1080中。本申请中处理器1080可以运行操作系统、应用程序、用户界面显示及触控响应，以及本申请实施例的数据库性能分析方法。另外，处理器1080与显示单元1030耦接。

在一些可能的实施方式中，本申请提供的数据库性能分析方法的各个方面还可以实现为一种程序产品的形式，其包括计算机程序，当程序产品在电子设备上运行时，计算机程序用于使电子设备执行本说明书上述描述的根据本申请各种示例性实施方式的数据库性能分析方法中的步骤，例如，电子设备可以执行如图3中所示的步骤。

程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

本申请的实施方式的程序产品可以采用便携式紧凑盘只读存储器(CD-ROM)并包括计算机程序，并可以在计算装置上运行。然而，本申请的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被命令执行系统、装置或者器件使用或者与其结合使用。

可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读计算机程序。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由命令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的计算机程序可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本申请操作的计算机程序，程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。计算机程序可以完全地在用户计算装置上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算装置上部分在远程计算装置上执行、或者完全在远程计算装置或服务器上执行。在涉及远程计算装置的情形中，远程计算装置可以通过任意种类的网络包括局域网(LAN)或广域网(WAN)连接到用户计算装置，或者，可以连接到外部计算装置(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了装置的若干单元或子单元，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。反之，上文描述的一个单元的特征和功能可以进一步划分为由多个单元来具体化。

此外，尽管在附图中以特定顺序描述了本申请方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用计算机程序的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序命令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序命令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的命令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序命令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的命令产生包括命令装置的制造品，该命令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序命令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的命令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims

1.一种数据库性能分析方法，其特征在于，该方法包括：

基于所述性能分析结果，对所述数据库进行运行情况预测。

2.如权利要求1所述的方法，其特征在于，所述不同的处理级别至少包括：记录处理级别和节点处理级别；每个处理节点为计算节点或存储节点；

所述基于所述目标日志信息对所述数据库进行性能分析，获得性能分析结果，包括：

基于所述记录处理时耗信息，对所述数据库进行性能分析。

3.如权利要求2所述的方法，其特征在于，所述记录处理时耗信息包括存储节点的数据读取时长；

在所述基于所述记录处理时耗信息，对所述数据库进行性能分析之前，还包括：

4.如权利要求2所述的方法，其特征在于，所述记录处理时耗信息包括存储节点的数据返回时长；

5.如权利要求1所述的方法，其特征在于，所述不同的处理级别至少包括：语句处理级别；

所述方法还包括：

6.如权利要求1所述的方法，其特征在于，所述目标日志信息包括：各个资源在第一预设时间段内的第一访问量；

7.如权利要求6所述的方法，其特征在于，所述方法还包括：

8.如权利要求1所述的方法，其特征在于，所述不同处理级别至少包括：语句处理级别；所述目标日志信息包括：一个查询语句相关的不同查询方式各自对应的执行时长；

所述方法还包括：

基于所述目标查询方式执行所述一个查询语句。

9.如权利要求1～8任一项所述的方法，其特征在于，所述不同处理级别至少包括节点处理级别；

10.如权利要求9所述的方法，其特征在于，所述基于所述性能分析结果，对所述数据库进行运行情况预测，包括：

11.一种数据库性能分析装置，其特征在于，该装置包括：

12.如权利要求11所述的装置，其特征在于，所述不同的处理级别至少包括：记录处理级别和节点处理级别；每个处理节点为计算节点或存储节点；所述分析单元具体用于：

基于所述记录处理时耗信息，对所述数据库进行性能分析。

13.一种电子设备，其特征在于，其包括处理器和存储器，其中，所述存储器存储有计算机程序，当所述计算机程序被所述处理器执行时，使得所述处理器执行权利要求1～10中任一所述方法的步骤。

14.一种计算机可读存储介质，其特征在于，其包括计算机程序，当所述计算机程序在电子设备上运行时，所述计算机程序用于使所述电子设备执行权利要求1～10中任一所述方法的步骤。

15.一种计算机程序产品，其特征在于，包括计算机程序，所述计算机程序存储在计算机可读存储介质中；当电子设备的处理器从所述计算机可读存储介质读取所述计算机程序时，所述处理器执行所述计算机程序，使得所述电子设备执行权利要求1～10中任一所述方法的步骤。