CN112256442A - 一种数据库死锁检测方法及装置 - Google Patents

Abstract

一种数据库死锁检测方法，包括：统计设定时长内数据库事务的SQL执行信息，生成死锁检测指标；根据死锁检测指标，监控实时数据库事务的SQL执行信息；当实时数据库事务的SQL执行信息满足死锁检测指标，则进行死锁检测。本申请可以降低资源消耗，并提升数据库整体执行效率。

Description

一种数据库死锁检测方法及装置

技术领域

本申请实施例涉及但不限于数据处理技术领域，尤指一种数据库死锁检测方法及装置。

背景技术

在数据库系统中，为了保证数据一致性，当一个数据库事务修改某一数据时，数据库系统会将该数据进行锁定，以使其他数据库事务无法修改该数据。在多个数据库事务并发执行时，会有一定几率存在两个或两个以上的数据库事务之间出现互相等待而停滞不前的现象，这就是死锁。

目前的死锁检测机制主要有以下三种：第一种、通过超时机制，等待锁释放；第二种、实时进行死锁冲突的检测，即维护全局锁资源占用信息，汇总所有锁的状态，进行全局有向环图构建，判断是否成环；第三种、通过提前检测方式对死锁进行预防。

然而，在第一种方式中，若超时时长设置太短，会导致事务失败率提高，而超时时长设置太长，会导致死锁无法被及时发现，锁资源被长时间占用，相关数据无法被访问，进一步增加死锁冲突的可能性；而且，在死锁概率大的场景下，会导致较为严重的资源浪费，且有可能在释放死锁后导致重复死锁。第二种方式需要实时同步信息，对资源消耗极大；特别地，在分布式场景下，节点数较多，实时进行全局锁冲突检测，会花费大量网络资源和计算资源，实时同步信息可能会成为性能瓶颈，且会导致数据库无法水平扩容。第三种方式中，只要存在锁冲突，就会对相关事务进行中止或重启，而实际上这些事务可能并不会产生死锁，只是出现了锁占用未释放(如事务执行时长较长)，存在大量误杀的可能；而且，针对等待-死亡(wait-die)和伤害-等待(wound-wait)死锁预防模式，均需要在行为判断上花费大量的资源，在死锁概率较小的场景下，耗费大量资源且影响数据库性能。

发明内容

本申请提供了一种数据库死锁检测方法及装置，可以降低资源消耗，并提升数据库整体执行效率。

一方面，本申请提供一种数据库死锁检测方法，包括：统计设定时长内数据库事务的结构化查询语言(SQL)执行信息，生成死锁检测指标；根据所述死锁检测指标，监控实时数据库事务的SQL执行信息；当所述实时数据库事务的SQL执行信息满足所述死锁检测指标，则进行死锁检测。

另一方面，本申请提供一种数据库死锁检测装置，包括：SQL统计模块、SQL执行模块以及死锁检测模块；所述SQL统计模块，用于统计设定时长内数据库事务的SQL执行信息，生成死锁检测指标；所述SQL执行模块，用于根据所述死锁检测指标，监控实时数据库事务的SQL执行信息；以及当所述实时数据库事务的SQL执行信息满足所述死锁检测指标，触发所述死锁检测模块进行死锁检测。

另一方面，本申请提供一种计算机可读存储介质，存储有计算机程序，所述计算机程序被执行时实现上述的数据库死锁检测方法的步骤。

在本申请中，统计设定时长内数据库事务的SQL执行信息，生成死锁检测指标；根据死锁检测指标，监控实时数据库事务的SQL执行信息；当实时数据库事务的SQL执行信息满足死锁检测指标，则进行死锁检测。本申请通过统计数据库内部全局的SQL执行信息，结合不同的实时数据库事务的SQL执行情况，来确定何时触发死锁检测，从而通过降低死锁检测的频率来降低资源消耗。

在一示例性实施例中，针对不同数据库事务包括的不同类别的SQL语句可以采用不同的死锁检测策略，避免采用通用策略而造成资源浪费，并提升数据库整体执行效率。

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

附图说明

附图用来提供对本申请技术方案的进一步理解，并且构成说明书的一部分，与本申请的实施例一起用于解释本申请的技术方案，并不构成对本申请技术方案的限制。

图1为本申请实施例的实施架构示意图；

图2为本申请实施例提供的数据库死锁检测装置内各模块的交互示意图；

图3为本申请实施例提供的数据库死锁检测方法的流程图；

图4为本申请实施例提供的数据库死锁检测方法的一种示例流程图；

图5为本申请实施例中SQL执行超时触发死锁检测的流程示例图；

图6为本申请实施例中单节点检测升级为全局检测的流程示例图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚明白，下文中将结合附图对本申请的实施例进行详细说明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。

在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

针对目前的死锁检测机制无法兼顾效率和资源的问题，本申请实施例提供一种数据库死锁检测方法及装置，基于在数据库内部统计的全局SQL执行信息，来计算何时触发死锁检测，从而通过降低死锁检测的频率来降低资源消耗。其中，针对不同的SQL类别，可以采用不同的死锁检测策略，从而避免因采用通用策略而造成资源浪费，并提升数据库整体执行效率。

本实施例中，数据库事务是访问并可能更新数据库中各种数据项的一个程序执行单元。一个数据库事务可以包括一条SQL语句、一组SQL语句或整个程序。其中，可以将匹配条件去除后剩余部分相同的SQL语句归属于同一SQL类别，比如，select name from tablewhere id＝1；select name from table where id＝2，这两条SQL语句都可以归类为以下SQL类别：select name from table where id＝*。关于SQL类别的限定可以根据实际应用进行设定。

本申请实施例提供的数据库死锁检测方法及装置，可以应用于分布式数据库系统。图1为本申请实施例的实施架构示意图。如图1所示，分布式数据库系统可以包括：多个计算节点(比如，计算节点1和2)和多个数据节点(比如，数据库1、2……n)。本申请对于分布式数据库系统内的计算节点和数据节点的数目并不限定。

在本实施例中，不同的数据库组可以承载不同的用户数据。分布式数据库系统以数据服务的方式向应用提供数据库服务。分布式数据库系统可以通过计算节点集群对外提供服务，计算节点可以采用无共享架构，对应用提供统一的标准SQL接口。如图1所示，应用服务器可以将业务请求发送到计算节点，计算节点将业务请求转发至数据节点执行。

本申请实施例提供的数据库死锁检测装置，可以应用于如图1所示的分布式数据库系统，包括：SQL统计模块、SQL执行模块以及死锁检测模块；其中，SQL统计模块，用于统计设定时长内数据库事务的SQL执行信息，生成死锁检测指标；SQL执行模块，用于根据死锁检测指标，监控实时数据库事务的SQL执行信息；当实时数据库事务的SQL执行信息满足死锁检测指标，则触发死锁检测模块进行死锁检测。

如图1所示，本实施例提供的数据库死锁检测装置可以部署在分布式数据库系统的计算节点内。其中，SQL统计模块可以根据实现方式不同，设计为集中式统计模块或分布式统计模块，比如，每个计算节点内的SQL统计模块可以具有分布式统计功能，用于统计所在计算节点上的SQL执行信息。然而，本申请对此并不限定。需要说明的是，在本实施例中，每个计算节点内的SQL统计模块向SQL执行模块推送的死锁检测指标是根据统计得到的全局的SQL执行信息确定的。

在一示例中，每个计算节点内的SQL统计模块负责统计设定时长内该计算节点上的SQL执行信息；例如，SQL执行信息可以包括每个SQL语句的最大执行时长和最大锁占用时长。其中，该计算节点内的SQL执行模块可以从数据库采集SQL执行信息，并将采集的SQL执行信息上报给对应的SQL统计模块。

在本示例中，可以由其中一个计算节点内的SQL统计模块根据采集到的全局的SQL执行信息，筛选出每个SQL类别对应的置信区间，然后，根据该SQL类别对应的置信区间内的SQL语句的最大执行时长和设定阈值(比如，超出10％)，来计算出该SQL类别的执行时长阈值，根据该SQL类别对应的置信区间内的SQL语句的最大锁占用时长和设定阈值(比如，超出10％)，来计算出该SQL类别的锁占用时长阈值。比如，该SQL类别的锁占用时长阈值等于置信区间内的SQL语句的最大锁占用时长的均值与设定阈值的乘积，例如，设定阈值为超出10％，则锁占用时长阈值可以为最大锁占用时长的1.1倍；然而，本申请对此并不限定。其中，可以根据任一SQL类别对应的全部SQL语句的最大执行时长，查看最大执行时长的分布情况，根据分布情况，确定SQL语句的置信区间，比如，置信区间可以包括占SQL语句总量的95％的SQL语句。然而，本申请对此并不限定。

需要说明的是，计算得到锁占用时长阈值所采用的设定阈值与计算得到执行时长阈值所采用的设定阈值可以相同或不同，本申请对此并不限定。

在一示例中，SQL统计模块可以根据周期性或定时统计的全局SQL执行信息，生成死锁检测指标。其中，死锁检测指标可以包括任一SQL类别的SQL执行阈值，比如，执行时长阈值、锁占用时长阈值。其中，SQL统计模块可以周期性或定时将根据统计的全局SQL执行信息生成的死锁检测指标同步给SQL执行模块。例如，在白天SQL统计模块可以每隔5分钟向SQL执行模块推送一次死锁检测指标，在夜间可以每隔1小时推送一次死锁检测指标；或者，SQL统计模块也可以根据分布式数据库系统的繁忙程度自适应地修改推送间隔。比如，在一示例中，针对任一SQL类别，当该SQL类别对应的运行指标平稳(例如，连续N天的最大执行时长中任两天之间的最大执行时长之差小于设定值)，则可以自动降低同步频率，即SQL统计模块可以增大该SQL类别的SQL执行阈值的推送间隔；当该SQL类别对应的运行指标变化较大，则可以自动增大同步频率，即SQL统计模块可以缩短该SQL类别的SQL执行阈值的推送间隔。如此一来，SQL统计模块可以根据实际业务模型，周期性向SQL执行模块推送适应业务模型的死锁检测指标，从而智能地更新死锁检测指标，实现对资源和效率的兼顾。

在本示例性实施例中，SQL执行模块会缓存SQL统计模块同步过来的死锁检测指标，并在执行实时数据库事务的SQL语句时，精确匹配对应的死锁检测指标，并根据匹配结果来确定是否需要触发死锁检测模块进行死锁检测。比如，当SQL执行模块实时执行的某一SQL语句的执行时长大于该SQL语句所属的SQL类别的执行时长阈值，则触发进行死锁检测。在本实施例中，由于死锁检测指标包括一个或多个SQL类别的执行阈值，因此，针对不同类别的SQL语句的执行情况，可以采用不同的死锁检测策略，从而可以避免由于采用通用策略而造成的资源浪费。

在本示例性实施例中，当SQL执行模块确认触发死锁检测，则SQL执行模块会向死锁检测模块发送死锁检测请求，其中，死锁检测请求可以携带触发进行死锁检测的SQL语句的信息以及该SQL语句所属的数据库事务的信息。死锁检测模块负责接收SQL执行模块发来的死锁检测请求，并根据死锁检测请求进行单节点锁信息查询或全局节点死锁检测。在检测结束后，当确认存在死锁冲突，则SQL执行模块可以根据设置的死锁拆除策略拆除死锁。在一示例中，死锁拆除策略可以包含以下任一方式：等待-死亡、伤害-等待。其中，等待-死亡方式可以包括：当数据库事务1请求的资源正被数据库事务2占有时，只有当数据库事务1的时间戳比数据库事务2的时间戳小时，数据库事务1才能等待，否则，数据库事务1即死亡；伤害-等待方式可以包括：当数据库事务1请求的资源正被数据库事务2占有时，只有当数据库事务1的时间戳比数据库事务2的时间戳大时，数据库事务1才能等待，否则数据库事务1即死亡。然而，本申请对此并不限定。

图2为本申请实施例提供的数据库死锁检测装置内各模块的交互示意图。图2示意出一个计算节点内的各模块的交互流程。在图2中，粗黑箭头线条表示统计信息同步消息流，虚线表示死锁检测消息流，细黑箭头线条表示SQL请求执行过程。

如图2所示，数据库死锁检测装置内各模块的交互过程包括：

S201、在起始运行阶段，SQL统计模块将默认的死锁检测指标(比如，通用的死锁检测指标)推送给SQL执行模块，SQL执行模块在一段时间内进行正常的业务执行，并使用默认的死锁检测指标对实时业务的SQL执行情况进行监控。

S202、随着业务运行，SQL执行模块不断地采集SQL执行信息并上报给SQL统计模块。

S203、SQL统计模块根据采集到的SQL执行信息实时生成新的死锁检测指标，新的死锁检测指标是对应当前业务场景的专用的死锁检测指标，例如包括SQL执行时长阈值。其中，以SQL执行时长为例，SQL统计模块可以根据SQL执行时长的变化量的速率，决定是否立即将新的死锁检测指标推送给SQL执行模块。比如，当SQL执行时长的变化速率较慢，则可以减慢死锁检测指标的同步速度，否则，可以加快同步速度。

S204、SQL执行模块重新加载新的死锁检测指标，根据新的死锁检测指标对业务SQL执行情况进行监控。比如，监控数据库事务的SQL语句的执行时长，当某一SQL语句的执行时长达到该SQL语句所属的SQL类别的执行时长阈值，则触发死锁检测。

S205、当SQL执行模块监测到一个SQL语句的执行超时(即，SQL语句的执行时长大于该SQL语句所属的SQL类别的执行时长阈值)，则直接下发死锁检测请求给死锁检测模块。

S206、死锁检测模块判断当前是否正在进行全局死锁检测，如果正在进行全局死锁检测，则直接使用全局死锁检测的相关数据进行死锁判断；如果当前不再进行全局死锁检测，则根据SQL执行模块下发的死锁检测请求携带的信息(比如，触发死锁检测的SQL语句对应的数据库事务的信息)优先触发单节点锁信息查询(即，在触发死锁检测的SQL语句涉及的数据节点进行锁信息查询)，在发现存在死锁的可能后，将检测上升为全局死锁检测。

其中，死锁检测可以利用构建有向图的方式进行。然而，本申请对此并不限定。

S207、死锁确认存在后，SQL执行模块向数据节点下发事务中止或者重启命令。

在本实施例中，通过SQL统计模块先统计出设定时长内全局的SQL执行信息，生成死锁检测指标，然后同步给SQL执行模块，SQL执行模块在执行各条SQL语句时，实时监控SQL执行情况，并将实时监控的SQL执行情况与死锁检测指标进行对比，一旦满足死锁检测指标，则触发进行死锁检测。在检测到死锁后，可以根据配置的死锁拆除策略，对检测出来的存在死锁的数据库事务进行中止(kill)或者重启，以将死锁解除。如此一来，能够以最低代价发现死锁冲突，最少化资源占用；而且，不会出现对正常事务的误操作，降低事务的失败率。

图3为本申请实施例提供的一种数据库死锁检测方法的流程图。如图3所示，本申请实施例提供的数据库死锁检测方法，包括：

S301、统计设定时长内数据库事务的SQL执行信息，生成死锁检测指标；

S302、根据死锁检测指标，监控实时数据库事务的SQL执行信息；

S303、当实时数据库事务的SQL执行信息满足死锁检测指标，则进行死锁检测。

在本实施例中，当实时数据库事务的SQL执行信息不满足死锁检测指标，可以返回S302，继续监控实时数据库事务的SQL执行信息。

在一示例性实施方式中，死锁检测指标可以包括：一个或多个SQL类别的SQL执行阈值。在一示例中，SQL执行阈值可以包括：执行时长阈值、锁占用时长阈值。然而，本申请对此并不限定。在其他实现方式中，还可以根据其他SQL执行参数来得到SQL执行阈值。

在本示例性实施方式中，SQL执行阈值可以包括以下至少之一：执行时长阈值、锁占用时长阈值；实时数据库事务的SQL执行信息满足死锁检测指标，可以包括以下至少之一：针对实时数据库事务包括的任一SQL语句，该SQL语句的最大执行时长大于该SQL语句所属的SQL类别的执行时长阈值；该SQL语句的最大锁占用时长大于该SQL语句所属的SQL类别的锁占用时长阈值。

在一示例中，数据库事务的SQL执行信息可以包括：数据库事务包括的任一SQL语句的最大执行时长；死锁检测指标可以包括任一SQL类别的执行时长阈值；当实时数据库事务包括的一个SQL语句的最大执行时长大于该SQL语句所属的SQL类别的执行时长阈值，则确认实时数据库事务的SQL执行信息满足死锁检测指标。或者，在一示例中，数据库事务的SQL执行信息可以包括：数据库事务包括的任一SQL语句的最大执行时长、最大锁占用时长；死锁检测指标可以包括任一SQL类别的执行时长阈值和锁占用时长阈值；当实时数据库事务包括的一个SQL语句的最大执行时长大于该SQL语句所属的SQL类别的执行时长阈值，且该SQL语句的最大锁占用时长大于该SQL语句所属的SQL类别的锁占用时长阈值，则确认实时数据库事务的SQL执行信息满足死锁检测指标。然而，本申请对此并不限定。

在一示例性实施方式中，S301可以包括：统计设定时长内数据库事务包括的每个SQL语句的SQL执行信息；确定每个SQL语句归属的SQL类别；针对任一SQL类别，根据归属于该SQL类别的SQL语句的SQL执行信息，筛选出置信区间内的SQL语句；根据置信区间内的SQL语句的SQL执行信息以及设定阈值，计算出该SQL类别的执行阈值。比如，针对任一SQL类别，可以根据置信区间内的SQL语句的最大执行时长和第一设定阈值(比如，可以预先配置或采用默认值)，计算出该SQL类别的执行时长阈值；根据置信区间内的SQL语句的最大锁占用时长和第二设定阈值(比如，可以预先配置或采用默认值)，计算出该SQL类别的锁占用时长阈值。

在一示例性实施方式中，在S303中，进行死锁检测，可以包括：针对满足所述死锁检测指标的SQL语句，查找该SQL语句占用的数据上是否存在锁等待的SQL语句；当该SQL语句占用的数据上存在锁等待的SQL语句，则执行全局死锁检测。在本示例性实施方式中，先检测执行的SQL语句涉及的数据上是否存在锁占用，在发现存在死锁可能后，再将检测上升为全局死锁检测，从而降低资源消耗。

在一示例性实施方式中，本实施例提供的数据库死锁检测方法还可以包括：在检测到存在死锁之后，根据数据库的死锁拆除策略进行处理。其中，设置的死锁拆除策略可以包括以下至少之一：等待-死亡、伤害-等待。然而，本申请对此并不限定。

在一示例性实施方式中，本实施例提供的数据库死锁检测方法还可以包括：周期性更新统计到的SQL执行信息；针对任一SQL类别，当该SQL类别对应的SQL执行信息满足设定条件时，更新死锁检测指标内该SQL类别的SQL执行阈值，并根据更新后的死锁检测指标，监控实时数据库事务的SQL执行信息。其中，全局的SQL执行信息的统计过程可以周期性或定时进行，是否采用更新后的死锁检测指标可以根据统计的SQL执行信息是否满足设定条件来确定。比如，针对任一SQL类别，设定条件可以包括：该SQL类别在一定时间段内对应的SQL执行时长保持平稳。

下面参照图4至图6，结合图1和图2所示的数据库死锁检测装置对本申请实施例提供的数据库死锁检测方法进行举例说明。

图4为本申请实施例提供的数据库死锁检测方法的一种示例流程图。如图4所示，本示例性实施例的数据库死锁检测流程包括：

S401、在应用服务器刚开始连接分布式数据库系统时(即起始运行阶段)，SQL统计模块没有统计到的死锁检测指标，则SQL统计模块会给出一个通用的死锁检测指标，SQL执行模块加载通用的死锁检测指标。

S402至S403、在一段时间内(时间跨度可以配置，时间跨度配置越小，采集信息生效越快，配置越大，采集信息生效越准确)，SQL统计模块持续采集SQL执行信息。

S404、SQL统计模块使用这段时间内采集的SQL执行信息，生成适应业务模型的死锁检测指标。

S405、SQL统计模将新生成的死锁检测指标推送给SQL执行模块。

S406、SQL执行模块使用新的死锁检测指标替代原有通用的死锁检测指标，进行业务监控。

S407、在SQL执行模块的执行过程中，如果监控到满足死锁检测指标的情况，则通知死锁检测模块进行死锁检测。

S408、死锁检测模块进行死锁检测，其中，优先进行本地锁信息检测，如果有必要才会升级为全局死锁检测。

S409、判断是否存在全局死锁。若存在，则转S410，否则，转S411，即无全局死锁，不需要额外处理。

S410、当判断出确实存在死锁时，按照死锁拆除策略进行处理，比如，重启或中止冲突的数据库事务。

图5为本申请实施例提供的SQL执行超时触发死锁检测的示意图。如图5所示，本示例性实施例的流程包括：

S501、SQL执行模块在执行数据库事务的SQL语句之前，先从SQL统计模块提供的死锁检测指标中找到该SQL语句所属的SQL类别的执行时长阈值，并记录该SQL语句的执行开始时间点。

S502、SQL执行模块根据该SQL语句的执行开始时间点和对应的执行时长阈值，设置回调函数，回调函数会触发死锁检测。

S503、判断该SQL语句是否在回调函数触发前执行完成；当SQL语句执行正常，在回调函数触发前完成，不会触发死锁检测，则转S510；当SQL语句的执行时长超过执行时长阈值，则转S504。

S504、当SQL语句的执行时长超过执行时长阈值，SQL执行模块触发死锁检测模块进行死锁检测。

S505、死锁检测模块接收到SQL执行模发送的死锁检测请求后，先进行单节点锁占用检测，即检测该SQL语句占用的数据上是否存在锁等待。

S506、死锁检测模块通过单节点检测，判断该SQL语句占用数据上是否存在锁等待，若没有，则不会出现全局死锁，转S510；否则，转S507。

S507、如果存在锁等待，则死锁检测模块将检测升级为全局死锁检测。

S508、死锁检测模块确定是否存在全局死锁；若不存在，则转S510；否则，转S509。

S509、当存在全局死锁，SQL执行模块可以进行事务冲突处理，比如，重启或中止冲突事务。

S510、当不存在全局死锁，不需要额外处理。

图6为本申请实施例提供的单节点检测升级为全局检测流程的示意图。如图6所示，本示例性实施例的流程包括：

S601、SQL执行模块在监控到满足死锁检测指标的SQL事务后，向死锁检测模块发送死锁检测请求，死锁检测请求中携带满足死锁检测指标的数据库事务的信息；死锁检测模块接收到死锁检测请求后，在该数据库事务的SQL语句涉及到的数据节点上查找相关的锁信息(比如，包括：被占用数据的信息、占用该数据的数据库事务的信息等)。

S602、判断该数据库事务的SQL语句是否存在长时间锁占用；若存在，则转S603，否则，转S610。

S603、当该数据库事务的SQL语句存在长时间锁占用，则死锁检测模块查找该SQL语句占用的数据上的锁等待SQL及对应的数据库事务的标识(ID)。

S604、根据查找到的数据库事务的ID从计算节点上查找对应的分布式信息，即该数据库事务涉及哪些分布式数据节点。

S605、到这些相关的数据节点上分别查找各个数据库事务是否存在长时间锁占用，且锁占用的数据行上是否存在其它的锁等待。

S606、将这些相关的数据节点上查找到的信息进行汇总，生成有向图。

S607、根据有向图，判断是否存在全局死锁；若存在，则转S609，否则，转S608。

S608、判断有向图是否存在后续节点；若存在，则转S604；否则，转S610。

S609、当存在全局死锁，则SQL执行模块按照死锁拆除策略进行死锁拆除处理，比如，重启或中止冲突事务。

S610、无全局死锁，不需要额外处理。

本申请实施例提供的数据库死锁检测方法及装置，针对正常的数据库事务，不论执行时长的长短，都能尽量少地触发死锁检测，而对于产生死锁冲突的数据库事务，则可以尽快地检测出死锁。

本申请实施例可以通过降低死锁检测的频率来降低资源消耗。本实施例中可以智能地对不同的SQL类别采用不同的死锁检测策略，避免因采用通用策略而造成的资源浪费，并提升数据库整体执行效率。

此外，本申请实施例还提供一种计算机可读存储介质，存储有计算机程序，所述计算机程序被执行时实现如上所述的数据库死锁检测方法的步骤。

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些组件或所有组件可以被实施为由处理器，如数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。

Claims (10)

1.一种数据库死锁检测方法，包括：

统计设定时长内数据库事务的结构化查询语言SQL执行信息，生成死锁检测指标；

根据所述死锁检测指标，监控实时数据库事务的SQL执行信息；

当所述实时数据库事务的SQL执行信息满足所述死锁检测指标，则进行死锁检测。

2.根据权利要求1所述的方法，其特征在于，所述死锁检测指标包括：一个或多个SQL类别的SQL执行阈值。

3.根据权利要求2所述的方法，其特征在于，所述SQL执行阈值包括以下至少之一：执行时长阈值、锁占用时长阈值；

所述实时数据库事务的SQL执行信息满足所述死锁检测指标，包括以下至少之一：

针对所述实时数据库事务包括的任一SQL语句，所述SQL语句的最大执行时长大于所述SQL语句所属的SQL类别的执行时长阈值；

所述SQL语句的最大锁占用时长大于所述SQL语句所属的SQL类别的锁占用时长阈值。

4.根据权利要求2所述的方法，其特征在于，所述统计设定时长内数据库事务的SQL执行信息，生成死锁检测指标，包括：

统计设定时长内数据库事务包括的每个SQL语句的SQL执行信息；

确定每个SQL语句归属的SQL类别；

针对任一SQL类别，根据归属于所述SQL类别的SQL语句的SQL执行信息，筛选出置信区间；根据置信区间内的SQL语句的SQL执行信息以及设定阈值，计算出所述SQL类别的执行阈值。

5.根据权利要求1所述的方法，其特征在于，所述进行死锁检测，包括：

针对满足所述死锁检测指标的SQL语句，查找所述SQL语句占用的数据上是否存在锁等待的SQL语句；

当所述SQL语句占用的数据上存在锁等待的SQL语句，则执行全局死锁检测。

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

在检测到存在死锁之后，根据数据库的死锁拆除策略进行处理。

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

周期性更新统计到的SQL执行信息；

针对任一SQL类别，当所述SQL类别对应的SQL执行信息满足设定条件时，更新所述死锁检测指标内所述SQL类别的SQL执行阈值，并根据更新后的死锁检测指标，监控实时数据库事务的SQL执行信息。

8.一种数据库死锁检测装置，其特征在于，包括：结构化查询语言SQL统计模块、SQL执行模块以及死锁检测模块；

所述SQL统计模块，用于统计设定时长内数据库事务的SQL执行信息，生成死锁检测指标；

所述SQL执行模块，用于根据所述死锁检测指标，监控实时数据库事务的SQL执行信息；以及当所述实时数据库事务的SQL执行信息满足所述死锁检测指标，触发所述死锁检测模块进行死锁检测。

9.根据权利要求8所述的装置，其特征在于，所述死锁检测指标包括：一个或多个SQL类别的SQL执行阈值。

10.一种计算机可读存储介质，其特征在于，存储有计算机程序，所述计算机程序被执行时实现如权利要求1至7中任一项所述的数据库死锁检测方法的步骤。

Images