CN115113989B - 事务执行方法、装置、计算设备及存储介质 - Google Patents

Abstract

本申请公开了一种事务执行方法、装置、计算设备及存储介质，属于数据库技术领域。本申请通过对DDL事务在DDL操作表中创建对应的DDL操作记录，使得DDL事务在完成对数据字典中存储的数据对象的定义的操作之后，无需等待在数据表中数据记录执行相关操作，即可提交DDL事务，这一在线DDL方式无需对数据表进行加锁，不会阻塞用户业务，例如，在智慧交通场景下，对新增停车位的描述信息的DDL事务进行在线执行，使得不会阻塞用户查询附近空闲停车位的DML事务，并且能够适用于各种不同操作类型的DDL事务，从而提供了一种针对各类不同操作类型的DDL事务的通用在线DDL执行方式，能够提升数据库系统的事务执行性能。

Description

事务执行方法、装置、计算设备及存储介质

技术领域

本申请涉及数据库技术领域，特别涉及一种事务执行方法、装置、计算设备及存储介质。

背景技术

随着数据库技术的发展，SQL（Structured Query Language，结构化查询语言）是一种数据库查询和程序设计语言，用于存取数据以及查询、更新和管理关系数据库系统。在SQL命令中涉及一类DDL（Data Definition Language，数据定义语言）语句，DDL语句是用于修改数据库中的对象（如表、索引、列、触发器等）的定义的语句。

目前，在对数据库中的某个对象执行DDL语句时，分为在线（Online）DDL和离线（非Online）DDL两种不同的执行方式，由于离线DDL方式对用户业务的阻塞较久，因此在线DDL是大数据场景下更广泛的执行方式。针对在线DDL方式，需要按照不同类型的DDL语句的具体语法进行定制化分析，才能够设计与实现DDL语句的在线执行，即，亟需一种针对各种不同类型的DDL语句通用的在线DDL执行方式。

发明内容

本申请实施例提供了一种事务执行方法、装置、计算设备及存储介质，能够提供一种针对各种不同类型的DDL语句通用的在线DDL执行方式。该技术方案如下：

一方面，提供了一种事务执行方法，该方法包括：

响应于数据定义语言DDL事务，在所述DDL事务所操作的数据对象与数据表中的数据列相关联的情况下，确定所述操作的操作类型；

基于所述操作类型，在所述数据表的DDL操作表中为所述操作创建对应的DDL操作记录，所述DDL操作表用于建立所述数据表中数据记录的不同版本之间的映射关系；

在所述数据表的数据字典中对所述数据对象的定义执行所述操作后，提交所述DDL事务。

一方面，提供了一种事务执行方法，该方法包括：

响应于数据操纵语言DML事务，获取所述DML事务所操作的数据表的数据定义语言DDL操作表；

基于所述DDL操作表，对所述DML事务在所述数据表中所涉及的数据记录进行对应的操作；

提交所述DML事务。

在一种可能实施方式中，所述基于所述DDL操作表，对所述DML事务在所述数据表中所涉及的数据记录进行对应的操作包括：

在所述DML事务涉及从所述数据表中删除数据记录的情况下，将所述DML事务指定删除的数据记录标记为删除状态。

一方面，提供了一种事务执行装置，该装置包括：

确定模块，用于响应于数据定义语言DDL事务，在所述DDL事务所操作的数据对象与数据表中的数据列相关联的情况下，确定所述操作的操作类型；

创建模块，用于基于所述操作类型，在所述数据表的DDL操作表中为所述操作创建对应的DDL操作记录，所述DDL操作表用于建立所述数据表中数据记录的不同版本之间的映射关系；

提交模块，用于在所述数据表的数据字典中对所述数据对象的定义执行所述操作后，提交所述DDL事务。

在一种可能实施方式中，所述创建模块包括：

生成单元，用于在解析所述DDL事务所涉及的每一项操作的操作类型时，对所述操作所涉及的每一个数据对象生成对应的操作解析信息；

存储单元，用于将所述DDL事务的各项操作所涉及的各个数据对象的所述操作解析信息，存储到操作解析信息集合中；

创建单元，用于在所述DDL操作表中，为所述操作解析信息集合中的每一个操作解析信息创建一条对应的所述DDL操作记录。

在一种可能实施方式中，对所述操作解析信息集合中的每一个操作解析信息，在所述操作解析信息所对应的数据对象为数据列的情况下，所述创建单元用于：

对每一个数据列的操作解析信息，在所述操作解析信息对应的操作类型为增加列的情况下，生成增加所述数据列的DDL操作记录；或，在所述操作解析信息对应的操作类型为删除列的情况下，生成删除所述数据列的DDL操作记录。

在一种可能实施方式中，对所述操作解析信息集合中的每一个操作解析信息，在所述操作解析信息所对应的数据对象为数据列的情况下，所述创建单元用于：

对每一个数据列的操作解析信息，在所述操作解析信息对应的操作类型为修改列的情况下，若所述数据列不具有关联的索引或者所述操作类型不涉及修改所述数据列的列类型，生成修改所述数据列的DDL操作记录。

在一种可能实施方式中，对所述操作解析信息集合中的每一个操作解析信息，在所述操作解析信息所对应的数据对象为数据列的情况下，所述创建单元用于：

对每一个数据列的操作解析信息，在所述操作解析信息对应的操作类型为修改列的情况下，若所述数据列具有关联的索引并且所述操作类型涉及修改所述数据列的列类型，将所述索引标记为仅允许写入状态，将所述数据列所在的数据表标记为检查状态，将所述DDL事务的跟踪信息置为未完成状态；生成修改所述数据列的DDL操作记录。

在一种可能实施方式中，所述装置还包括：

启动模块，用于对所述数据列所关联的所述索引，启动索引修改事务；

修改模块，用于响应于所述索引修改事务，修改所述数据列所在的数据表中的每一条数据记录和每一条数据记录所关联的索引记录；

标记模块，用于将所述数据表和所述索引均标记为发布状态；

所述提交模块，还用于在所述数据表的数据字典中，对所述数据列和所述索引的定义执行所述索引修改事务所指示的修改；

所述标记模块，还用于将所述DDL事务的跟踪信息置为已完成状态。

在一种可能实施方式中，所述修改模块包括：

转换单元，用于对所述数据表中存储的每一条数据记录，若所述数据记录并非最新版本，将所述数据记录转换为最新版本；

写入单元，用于将所述最新版本的数据记录写回所述数据表；

所述写入单元，还用于在所述数据记录所关联的索引记录中，写入所述最新版本的数据记录中与所述索引对应的字段数据，以覆盖已有的同一字段数据。

在一种可能实施方式中，所述转换单元包括：

查询子单元，用于查询所述数据表的DDL操作表，得到所述数据记录从当前版本到所述最新版本之间发生的至少一条DDL操作记录；

生成子单元，用于基于所述至少一条DDL操作记录，生成从所述当前版本到所述最新版本的字段映射关系；

映射子单元，用于基于所述字段映射关系，对所述数据记录的各个字段数据进行映射操作，得到所述最新版本的数据记录。

在一种可能实施方式中，所述映射子单元用于：

若所述DDL操作记录对应的操作类型包括新增列，向新增的数据列对应的字段数据中填充插入值或默认值；

若所述DDL操作记录对应的操作类型包括删除列，跳过被删除的数据列对应的字段数据；

若所述DDL操作记录对应的操作类型包括修改列位置，将被修改位置的数据列对应的字段数据从原始位置移动至目标位置；

若所述DDL操作记录对应的操作类型包括修改列类型，对被修改列类型的数据列对应的字段数据的数据类型从原始类型转换为目标类型。

在一种可能实施方式中，所述映射子单元还用于：

基于所述DDL事务的默认值设置方式，向所述字段数据中填充符合对应版本的默认值，所述对应版本包括所述数据记录的最新版本或者插入版本。

在一种可能实施方式中，对所述数据表中存储的每一条数据记录，若所述数据记录并非最新版本，且所述数据列的列类型转换存在冲突的情况下，所述装置还包括：

获取模块，用于获取所述DDL事务的异常处理参数；

第一转换模块，用于在所述异常处理参数指向异常处理函数时，基于所述操作类型下挂载的所述异常处理函数，对所述数据记录进行转换；

返回模块，用于在所述异常处理参数不指向异常处理函数，或所述异常处理函数对所述数据记录转换失败时，暂停所述索引修改事务，向触发所述DDL事务的设备返回发生冲突的所述数据记录。

在一种可能实施方式中，所述装置还包括：

第二转换模块，用于在符合转换条件时，对数据库中的每张数据表，调用对应的DDL操作表，将所述数据表中的每条数据记录均转换为最新版本。

一方面，提供了一种事务执行装置，该装置包括：

第一获取模块，用于响应于数据操纵语言DML事务，获取所述DML事务所操作的数据表的数据定义语言DDL操作表；

操作模块，用于基于所述DDL操作表，对所述DML事务在所述数据表中所涉及的数据记录进行对应的操作；

提交模块，用于提交所述DML事务。

在一种可能实施方式中，所述操作模块用于：

在所述DML事务涉及读取所述数据表中已存储的数据记录的情况下，若所述已存储的数据记录是最新版本，返回所述已存储的数据记录；若所述已存储的数据记录并非最新版本，基于所述DDL操作表，将所述数据记录转换为最新版本，返回转换得到的数据记录。

在一种可能实施方式中，所述装置还包括：

第二获取模块，用于获取所述已存储的数据记录的记录版本号和所述数据表的表结构定义的最新版本号；

确定模块，用于在所述记录版本号等于所述最新版本号的情况下，确定所述已存储的数据记录是最新版本；

所述确定模块，还用于在所述记录版本号小于所述最新版本号的情况下，确定所述已存储的数据记录并非最新版本。

在一种可能实施方式中，所述操作模块用于：

在所述DML事务涉及向所述数据表中写入数据记录的情况下，基于所述数据表的具有最新版本号的表结构定义，向所述数据表中写入符合所述表结构定义的数据记录。

在一种可能实施方式中，所述操作模块用于：

在所述DML事务涉及从所述数据表中删除数据记录的情况下，将所述DML事务指定删除的数据记录标记为删除状态。

一方面，提供了一种计算设备，该计算设备包括一个或多个处理器和一个或多个存储器，该一个或多个存储器中存储有至少一条计算机程序，该至少一条计算机程序由该一个或多个处理器加载并执行以实现如上述任一种可能实现方式的事务执行方法。

一方面，提供了一种存储介质，该存储介质中存储有至少一条计算机程序，该至少一条计算机程序由处理器加载并执行以实现如上述任一种可能实现方式的事务执行方法。

一方面，提供一种计算机程序产品或计算机程序，所述计算机程序产品或所述计算机程序包括一条或多条程序代码，所述一条或多条程序代码存储在计算机可读存储介质中。计算设备的一个或多个处理器能够从计算机可读存储介质中读取所述一条或多条程序代码，所述一个或多个处理器执行所述一条或多条程序代码，使得计算设备能够执行上述任一种可能实施方式的事务执行方法。

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

通过对DDL事务在DDL操作表中创建对应的DDL操作记录，使得DDL事务在完成对数据字典中存储的数据对象的定义的操作之后，无需等待在数据表中数据记录执行相关操作，即可提交DDL事务，这一在线DDL方式无需对数据表进行加锁，不会阻塞用户业务，并且能够适用于各种不同操作类型的DDL事务，从而提供了一种针对各类不同操作类型的DDL事务的通用在线DDL执行方式，能够提升数据库系统的事务执行性能。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还能够根据这些附图获得其他的附图。

图1是本申请实施例提供的一种事务执行方法的实施环境示意图；

图2是本申请实施例提供的一种事务执行方法的流程图；

图3是本申请实施例提供的一种数据记录的存储格式的原理性示意图；

图4是本申请实施例提供的一种事务执行方法的流程图；

图5是本申请实施例提供的一种索引修改事务的执行流程图；

图6是本申请实施例提供的一种字段提取转换操作的原理性示意图；

图7是本申请实施例提供的一种数据记录解析转换的原理性流程图；

图8是本申请实施例提供的一种周期性性能优化策略的原理性流程图；

图9是本申请实施例提供的一种在线DDL事务的原理性流程图；

图10是本申请实施例提供的一种DML事务的执行流程图；

图11是本申请实施例提供的一种DML事务执行过程的原理性流程图；

图12是本申请实施例提供的一种事务执行装置的结构示意图；

图13是本申请实施例提供的一种事务执行装置的结构示意图；

图14是本申请实施例提供的一种计算设备的结构示意图；

图15是本申请实施例提供的一种计算设备的结构示意图。

具体实施方式

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

本申请中术语“第一”“第二”等字样用于对作用和功能基本相同的相同项或相似项进行区分，应理解，“第一”、“第二”、“第n”之间不具有逻辑或时序上的依赖关系，也不对数量和执行顺序进行限定。

本申请中术语“至少一个”是指一个或多个，“多个”的含义是指两个或两个以上，例如，多个第一位置是指两个或两个以上的第一位置。

在介绍本申请实施例之前，需要引入一些云技术领域内的基本概念。

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

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

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

以下，对本申请实施例所涉及的术语进行解释说明。

计算设备：即计算节点或计算引擎节点，主要完成SQL（Structured QueryLanguage，结构化查询语言）层的计算功能，亦可称为SQL引擎（SQL Engine）。换言之，计算设备是指数据库（通常指集群数据库，对于单机数据库来说单机设备本身就是一个计算设备）中用来处理用户特定计算请求（简称用户请求），并主要负责执行用户请求的节点设备。

存储设备：即存储节点或存储引擎节点（Storage Engine），主要完成事务（Transaction）及存储功能。换言之，存储设备是指数据库中用来处理存储数据记录，并完成事务执行与提交的节点。

集群管理设备：即集群管理节点（Cluster Manager）或集群元信息管理器（MetaCluster，MC），负责管理整个集群数据库所必需的信息，例如，集群管理设备负责管理整个集群数据库中正在工作的计算设备，并支持新增或者移除计算设备等功能。

Schema（数据库中的数据对象）：Schema代表了数据库中的数据对象所构成的集合，数据库中的Schema数据对象包括：数据表（Table）、数据列（Column）、索引（Index）、约束（Constraints）、存储过程（Stored Procedures）、函数（Function）等。

DDL（Data Definition Language，数据定义语言）语句：即DDL语句操作，指用来修改数据库中的Schema数据对象（如：数据表、数据列、索引、触发器等）的定义的语句。例如，通用场景下用于修改数据表A的表名的语句属于DDL语句，智慧交通场景下用于新增停车位的描述信息的语句也属于DDL语句。

DML（Data Manipulate Language，数据操纵语言）语句：即DML语句操作，指用来增加、删除或修改数据表中的数据记录，DML语句通常伴随着由用户发起的业务操作（即业务事务）。例如，金融场景下用于查询账户余额的语句属于DML语句，智慧交通场景下用于查询附近空闲停车位的语句也属于DML语句。

非Online DDL（离线DDL）：离线DDL是传统的DDL语句的执行方式，即在执行DDL语句的期间，会锁定DDL语句（对应于DDL事务）所操作的数据记录（如数据表或索引），因此会阻塞在该DDL语句执行期间其他业务事务（如DML事务）对该数据对象中数据记录的修改，这样是为了保证DDL语句所操作的数据对象中所存储的数据记录的一致性。换言之，在DDL语句执行期间，用户发起的业务操作（业务事务）会因为该数据对象被锁定而阻塞。

Online DDL（在线DDL）：在线DDL是相对于离线 DDL 来说的，由于离线DDL方式下，在对数据库中的某个数据对象执行一个DDL语句时，都会对相应的该数据对象加上锁，然后执行相应的变更操作，导致DDL语句执行期间业务事务会因为该数据对象被锁定而阻塞。随着用户对于业务的高可用要求越来越高，各家数据库厂商都相应提出在线DDL的实现，即在对某个数据对象做DDL变更的时候，实现对于用户业务不阻塞或者只阻塞一个很小的时间段。

数据字典：数据库中用来存放数据库中的数据对象的定义（如元信息）的地方。其中，数据库中的数据对象包括但不限于：数据库、表空间、 数据表、数据列、索引、分区信息、用户、函数、角色等。

Tuple（数据记录）：通常是指关系型数据库中的数据表中的某一行数据记录，这个数据记录存储了数据表的定义中所有数据列的实例化信息（即每个数据列对应的字段数据），并按照数据列定义的顺序排列，组成一个连续的内容，也即是说，这段连续的内容被称为数据表的一条数据记录，即Tuple。

以下，对传统数据库中DDL语句的离线执行模式进行说明。

对于传统单机数据库系统，通过对元数据加锁的方式来阻塞有冲突的操作的执行，保证针对Schema数据对象的变更的正确执行，即保证DDL语句的正确执行。

对于传统集群数据库系统，集群数据库系统作为单机数据库系统的一个扩展，集群内包括多个计算节点（即计算设备），每个计算节点的数据库中存储有多个数据表，每个数据表中存储有一条或多条数据记录（即数据行），每一条数据记录由一组按照相同位置索引排列的字段数据所构成的字段集组成，即数据字段列，计算节点的数据库可以为任一类型的集群数据库，包括关系型数据库或者非关系型数据库中至少一项，例如SQL（Structured Query Language，结构化查询语言）数据库、MySQL、NoSQL、NewSQL（泛指各种新式的可拓展/高性能数据库）等，在本申请实施例中对数据库的类型不作具体限定。

针对上述集群数据库系统，DDL语句的执行模式划分为Share Memory（共享内存）模式和Share Nothing（零共享）模式：

A）Share Memory（共享内存）模式，通过在集群内的一个中央协调节点来控制各个计算节点对于某一个Schema数据对象的访问控制逻辑；

B）Share Nothing（零共享）模式，通常所有计算节点都有一个控制节点来确定哪些计算节点需要参与DDL语句的执行，然后DDL语句再分发到相应的计算节点执行，在每个计算节点中可以视为在一个单机数据库系统上执行，因此与单机数据库基本类似。

对于计算存储分离的云原生数据库架构，目前都只实现了单写，可以认为与MySQL单实例一致，在实现多写集群方案中，需要在多个写节点同步DDL锁以保证数据记录在DDL变更前后以及变更过程中的一致性。

针对上述传统数据库，如果想要将DDL语句从离线执行模式切换为在线执行模式，需要针对具体某类操作类型的DDL语句进行具体分析，单独为这一类DDL语句设计从离线DDL到在线DDL的策略，通常都是通过如下方式：建立一张新的临时表，拷贝原表中的数据记录到临时表中，在拷贝完毕后的某一时刻锁定原表，并将拷贝时期的日志在临时表上进行回放（即锁表追日志），最后切换原表与临时表，即，将临时表替换为原表，然后可异步删除原表。上述方式中，锁表追日志的期间由于需要对原表加锁，因此在锁表追日志的期间会对用户业务造成阻塞，并且，由于需要将拷贝一张和原表相同的临时表，因此需要和原表同样大小的存储空间，才能够完成DDL语句的执行。

此外，F1数据库或其他以F1为基础的数据库，针对增加列和增加索引的DDL语句提供了在线DDL模式，但是并不能覆盖到DDL语句涉及的各种各样的操作类型，如果想要实现如修改列等操作类型的DDL语句的在线DDL模式，也需要单独分析和设计如何从离线DDL到在线DDL的策略，因此局限性较高、通用性很差。

综上所述，不管是传统数据库的在线DDL实现，还是F1数据库的在线DDL实现，都是针对某一类或者几类特定操作类型的DDL语句提供在线DDL模式，而针对系统未支持的其他操作类型的DDL语句，都需要按照DDL语句的具体语法进行定制实现，具有很高的局限性，通用性很差。此外，对于DDL语句，如果在执行过程中发生了异常（例如，修改列类型后类型不兼容），则需要整体回滚整个DDL语句，DDL语句执行失败。

以下，举例说明一种DDL语句执行过程中可能发生的异常类型。

假设数据库中存在一张数据表T，数据表T中包含数据列c1，数据列c1的列类型定义为字符串类型，并且在数据列c1上原本还定义有一个唯一性索引unique_idx(c1)。在某一时刻对数据列c1的列类型进行DDL变更，将列类型从字符串类型转换为整型类型，假设原始的数据表T中包含如下数据记录：

记录1，c1 = “1”；

记录2，c1 = “ 1”；

记录3，c1 = “a1”；

针对数据表T中的数据列c1进行如下DDL语句（以MySQL语法为例）：Alter tableT1 change c1 c1 int; 此时会引发数据转换异常。

异常产生的理由如下：其一，上述DDL语句在执行到记录1和记录2转换的时候，记录1和记录2对应的字段c1转换后的数值都会是整型数据1（整型数据无法区分空格），因为数据列c1上面定义了唯一性索引，会导致整型数据1对应于两条记录，不满足唯一性索引的约束，因此如果在DDL语句执行过程中遇到此类问题，会回滚该DDL语句；其二，上述DDL语句在执行到记录3转换的时候，记录3的字段c1由于包含“a”字符，因此无法直接从字符串类型转换到整型类型，即发生了数据转换异常，同样会导致DDL语句执行失败。

有鉴于此，本申请实施例提供一种事务执行方法，能够提供通用的在线DDL方案，以支持用户以在线方式执行各类DDL语句，并且将原本可能需要在DDL语句执行期间进行转换的数据记录，异步到后续用户访问该数据记录时才会运行数据版本的转换逻辑，对于每条数据记录来讲转换时间几乎可以忽略，从而对用户生产业务的影响几乎为0，能够向数据库提供在执行DDL操作期间同时支持用户DML业务的功能，从而更好地为用户提供数据服务，并且作为通用的在线DDL框架，在框架搭建起来之后，能够灵活地实现分期分批各种粒度的从离线DDL到在线DDL的细粒度支持。

需要说明的是，本申请实施例可应用于单机数据库、集群数据库、计算存储分离的云原生数据库架构等各类数据库系统，此外，本申请实施例还可应用于一种基于区块链技术的数据库系统（以下简称为“区块链系统”），上述区块链系统在本质上属于一种去中心化式的分布式数据库系统，采用共识算法保持区块链上不同计算设备所记载的账本数据一致，通过密码算法保证不同计算设备之间账本数据的加密传送以及不可篡改，通过脚本系统来拓展账本功能，通过网络路由来进行不同计算设备之间的相互连接。

在区块链系统中可以包括一条或多条区块链，区块链是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性（防伪）和生成下一个区块。示意性地，在存储计算分离架构下，由各个已完成的DLL事务的日志记录作为账本数据，并构建区块链系统，在每个计算设备中各自存储一批次的网络交易信息（即日志记录），将网络交易信息上链之后由对应的各个存储设备通过链上的网络交易信息来追赶本地磁盘中数据记录的最新版本。

区块链系统中计算设备之间可以组成点对点（Peer To Peer，P2P）网络，P2P协议是一个运行在传输控制协议（Transmission Control Protocol，TCP）协议之上的应用层协议。在区块链系统中，任一计算设备可以具备如下功能：1）路由，计算设备具有的基本功能，用于支持计算设备之间的通信；2）应用，用于部署在区块链中，根据实际业务需求而实现特定业务，记录实现功能相关的数据形成账本数据，在账本数据中携带数字签名以表示数据来源，将账本数据发送至区块链系统中的其他计算设备，供其他计算设备在验证账本数据来源以及完整性成功时，将账本数据添加至临时区块中，其中，应用实现的业务可以包括钱包、共享账本、智能合约等；3）区块链，包括一系列按照先后的时间顺序相互接续的区块，新区块一旦加入到区块链中就不会再被移除，区块中记录了区块链系统中计算设备提交的账本数据。

在一些实施例中，每个区块中可以包括本区块存储交易记录的哈希值（本区块的哈希值）以及前一区块的哈希值，各区块通过哈希值连接形成区块链，另，区块中还可以包括有区块生成时的时间戳等信息。

以下，对本申请实施例的系统架构进行说明。

图1是本申请实施例提供的一种事务执行方法的实施环境示意图。参见图1，本申请实施例适用于单机数据库、集群数据库、计算存储分离的云原生数据库架构等各类数据库系统，下面以分布式集群数据库为例进行说明。分布式集群数据库系统中包括应用客户端101、网关服务器102以及分布式存储集群103，在分布式存储集群103中包括一个或多个计算设备（即计算节点）。

应用客户端101是指用户侧的终端上安装和运行的能够发起用户请求的客户端，该用户请求可以是DDL请求或者DML请求等，本申请实施例对此不进行具体限定。可选地，应用客户端101的类型包括但不限于：支付应用、社交应用、音视频应用、直播应用、购物应用、外卖应用或者打车应用等，本申请实施例不对应用客户端101的类型进行具体限定。

在一些实施例中，用户侧的终端也称为用户设备、终端设备、用户终端、移动终端、智能终端、通信设备等。可选地，终端的设备类型包括：智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表、车载终端、智能家电、智能语音交互设备等，但并不局限于此。

应用客户端101以及网关服务器102能够通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

网关服务器102用于接收外部的用户请求，并将用户请求对应的读写事务分发至分布式存储集群103，示意性地，用户在终端上登录应用客户端101，触发应用客户端101生成DDL请求，例如，DDL请求为修改数据表A的表名。调用分布式集群数据库系统提供的API（Application Programming Interface，应用程序编程接口）将该DDL请求发送至网关服务器102，比如，该API可以是MySQL API（一种关系型数据库系统提供的API）。又例如，在智慧交通场景下，新增停车位的描述信息请求为DDL请求，而查询已有停车位的请求为DML请求。

在一些实施例中，该网关服务器102可以与分布式存储集群103中的任一个计算设备合并在同一个物理机上，也即是，让某个计算设备充当网关服务器102。

分布式存储集群103包括一个或多个计算设备，本申请实施例不对分布式存储集群103中计算设备的数量进行具体限定，例如，计算设备的数量为m个，m为大于或等于1的整数。可选地，每个计算设备采用主备结构（也即是为一主多备集群），如图1所示，以计算设备为一主两备集群为例进行示意，每个计算设备中包括一个主机和两个备机，可选地，每个主机或备机都对应配置有代理（Agent）设备，代理设备可以与主机或备机是物理独立的，当然，代理设备还可以作为主机或备机上的一个代理模块，以计算设备1为例，计算设备1包括一个主数据库及代理设备（主database+agent，简称主DB+agent），此外还包括两备数据库及代理设备（备database+agent，简称备DB+agent）。

在一个示例性场景中，每个计算设备所对应的主机或备机的数据库实例集合称为一个SET（集合），例如，假设某一计算设备为单机设备，那么该计算设备的SET仅为该单机设备的数据库实例，假设某一计算设备为一主两备集群，那么该计算设备的SET为主机数据库实例以及两个备机数据库实例的集合。

在一些实施例中，上述网关服务器102以及分布式存储集群103所构成的分布式集群数据库系统，可以视为一种向用户终端提供数据服务的服务器，该服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN（Content Delivery Network，内容分发网络）、以及大数据和人工智能平台等基础云计算服务的云服务器。

以下，将对DDL语句即DDL事务所涉及的各类操作的操作类型进行说明。和数据记录相关的DDL语句包括如下几类：变更约束、变更索引和变更数据表。其中，针对变更数据表的操作类型，还能够详细划分成如下几个子类别：增加列、删除列、修改列名称、修改列位置、修改列类型和主键变更。

其中，针对操作类型为增加（Add）列的情况，新增加的数据列可位于数据记录中的任一字段，如果新增加的数据列位于数据记录的最后一个字段，则该操作类型还称为追加列，当然，除了在最后一个字段增加列以外的、向数据记录中新增数据列，也符合增加列的定义。

其中，针对操作类型为修改列类型的情况，包括如下几种针对列类型的修改操作：a）修改默认值；b）列类型兼容，例如，将某一数据列的列类型从int整型修改为bigint整型，由于bigint整型支持的数据范围大于int整型支持的数据范围，因此列类型兼容；c）列类型不兼容，例如，将某一数据列的列类型从varchar字符串修改为int整型，由于varchar字符串是一个字符集，如果在字符集上定义的字符序发生变化，也会认为字符类型发生变化，因此列类型不兼容。

需要说明的是，针对b）中列类型兼容的修改操作，如果涉及到列类型的数据范围缩小，例如bigint整型修改为int整型，又例如varchar（20）修改为varchar（10）等，其中varchar（20）代表字符串最大长度为20，varchar（10）代表字符串最大长度为10，这种涉及到列类型的数据范围缩小的修改操作，即使列类型兼容，也需要向用户进行告警，提示用户这种列类型的变更可能会造成部分数据丢失。此外，如果涉及到列类型的数据范围缩小，并且在数据列上还定义了唯一性索引或者二级索引，也需要在后台同步转换本数据列对应的唯一性索引或者二级索引的索引记录中对应字段数据的数据类型，以避免由于列类型的数据范围缩小导致索引查询结果异常的问题。

需要说明的是，针对c）中列类型不兼容的修改操作，按照数据列上是否定义了唯一的二级索引（即数据列上是否定义了唯一性索引），可进一步划分为数据列上没有定义唯一的二级索引和数据列上定义了唯一的二级索引两种情况。

其中，针对操作类型为主键变更的情况，由于涉及到用户主键查询唯一性的问题，可根据技术人员的设置，选择是否对涉及主键变更的DDL事务开启在线DDL模式。例如，针对主键中的数据列修改列类型且类型不兼容，由于主键数据存在不能实时反映用户数据的唯一性的可能，为避免给数据库的使用造成数据不一致的现象，可将所有涉及主键变更的DDL事务切换为离线DDL模式，在生产环境下主键类型变更基于代表数据库中数据表的表结构重构，支持在线的需求优先级不高，将涉及主键变更的DDL事务在线化对用户的价值也不大。

本申请实施例提供的事务执行方法，可适用于涉及上述列举的所有操作类型的DDL事务，对于数据库系统来说用户的业务事务即DML事务是最为普遍的一类事务，而通常数据库中会存储用户的数据记录的数据对象包括数据表和索引，因此针对用户的数据记录相关的数据对象（数据表和索引）进行操作的DDL事务会直接影响到用户业务的可用性，有鉴于此，在后续的几个实施例中将会以变更数据表为例，详细介绍如何将该事务执行方法应用到涉及变更数据表的DDL事务中，以实现通用地、灵活地在线DDL框架执行。

以下，将对DDL事务在在线DDL模式下执行和提交流程进行介绍，在线DDL模式能够满足用户对于在线修改DDL且不阻塞用户业务的需求，能够提高数据库系统的事务处理性能，从而提升运用该数据库系统的相关产品的竞争力。

图2是本申请实施例提供的一种事务执行方法的流程图，本申请实施例适用于单机数据库系统、集群数据库系统、分布式数据库系统、计算存储分离的云原生数据库架构、区块链系统等，在此不做具体限定。参见图2，该实施例由数据库系统中的任一计算设备执行，在本申请实施例中将介绍通用的在线DDL框架流程。

201、计算设备响应于数据定义语言DDL事务，在该DDL事务所操作的数据对象与数据表中的数据列相关联的情况下，确定该操作的操作类型。

在一些实施例中，用户在终端上登录应用客户端，触发应用客户端生成DDL请求，例如，DDL请求为向数据表A中新增一个数据列，或者，删除数据表中已有的某个数据列，或者，修改数据表中某个数据列的列类型等，本申请实施例不对DDL请求的类型进行具体限定。应用客户端在生成DDL请求之后，可调用API将该DDL请求发送至计算设备，比如，该API可以是MySQL API。

在一些实施例中，计算设备接收应用客户端的任一用户请求，解析该用户请求的头字段，当该头字段指示该用户请求为DDL请求时，解析该DDL请求的数据字段，得到该DDL请求中携带的DDL语句，基于该DDL语句可构建一个唯一对应的DDL事务。可选地，计算设备为该DDL语句创建一个新的DDL进程或线程，或者复用已创建的某一DDL进程或线程，并通过该DDL进程或线程执行该DDL语句对应的DDL事务。

在一些实施例中，计算设备对该DDL语句进行解析，以确定该DDL语句所涉及的每一项操作和每一项操作各自的操作对象和操作类型，其中，该DDL语句所涉及的操作的数量为一项或多项，本申请实施例不对该DDL语句所涉及的操作的数量进行具体限定。示意性地，用户可能在某一DDL请求的DDL语句中要求不止一项操作，比如，在某一DDL语句中要求删除数据列a1并追加数据列d1，这一DDL语句可分解为两项操作：新增列的操作和删除列的操作。

在一些实施例中，由于DDL事务的操作类型是多种多样的，如果DDL事务所操作的数据对象与数据表中的数据列无关，可跳过步骤202，直接执行步骤203。比如DDL事务用于修改数据表A的表名，只需要在数据表A的数据字典中对数据表A的定义进行修改即可，由于如修改表名等与数据表中的数据列无关的DDL事务，是不会影响到构建数据表中数据记录的不同版本之间的映射关系的，因此这一修改表名的操作并非必须要写入到下述步骤202的DDL操作表中。

在一些实施例中，对该DDL事务所涉及的每一项操作的操作对象，如果该操作对象本身就是数据列，或者该操作对象是建立在数据列上的索引或约束，则确定该DDL事务所操作的数据对象与数据表中的数据列相关联；否则，确定该DDL事务所操作的数据对象与数据表中的数据列无关联。

在一些实施例中，对该DDL事务所涉及的每一项操作的操作类型，如果该操作类型为变更索引，代表对应的操作对象是建立在数据列上的索引；如果该操作类型为变更约束且被变更的约束与数据列相关联，代表对应的操作对象是与数据列关联的约束；如果该操作类型命中下述任一项：增加列、删除列、修改列名称、修改列位置或修改列类型，代表对应的操作对象本身就是数据列；如果该操作类型为主键变更，则可基于当前数据库系统中是否对主键变更开放在线DDL权限，来确定是执行在线DDL流程还是切换为离线DDL流程。

202、计算设备基于该操作类型，在该数据表的DDL操作表中为该操作创建对应的DDL操作记录，该DDL操作表用于建立该数据表中数据记录的不同版本之间的映射关系。

其中，对数据表中存储的每一条数据记录，由于DDL事务或DML事务可能会对该数据记录进行增删改等操作，使得该数据记录具有多个不同的版本，需要说明的是这些不同的版本的数据记录都具有相同的主键ID，正是由于DDL操作表中记载的各个DDL操作记录可能尚未进行落盘，导致数据表中实际存储的可能并非是最新版本的数据记录，上述未及时落盘的原因可能是用户业务没有访问该条数据记录，或者后台处理线程没有对该条数据记录进行异步更新，相关更新过程会在后面的实施例中详细说明。通过该DDL操作表，能够建立起数据记录的任意两个版本（例如，存储版本到最新版本）之间的映射关系，由于每条DDL操作记录都会记载所操作的数据对象的版本号，而每条数据记录自身存储格式中会携带一个记录版本号，只需要在DDL操作表中找到位于记录版本号到最新版本号之间的各条DDL操作记录，就能够建立出数据记录的存储版本到最新版本之间的映射关系（例如，指字段映射关系），从而能够方便地将数据记录从存储版本转换到最新版本，整体保障了通用在线DDL框架下的数据一致性。需要说明的是，这里涉及的数据记录的存储版本，在后续的实施例中也称为“当前版本”，均是指在当前时刻下数据表中存储的数据记录所处的版本，即是与数据表中存储的数据记录的存储格式中的记录版本号对应的版本。

在一些实施例中，计算设备在上述步骤201中解析该DDL事务所涉及的每一项操作的操作类型时，对该操作所涉及的每一个数据对象生成对应的操作解析信息，由于该DDL事务可能涉及到一项或多项操作，而每一项操作可能涉及到一个或多个数据对象，因此，将该DDL事务的各项操作所涉及的各个数据对象的该操作解析信息，存储到操作解析信息集合中。接着，在该DDL操作表中，为该操作解析信息集合中的每一个操作解析信息创建一条对应的该DDL操作记录。

在上述过程中，通过在解析DDL事务的每一项操作时，记录其对应的操作解析信息并录入操作解析信息集合，从而在创建DDL操作记录时直接访问该操作解析信息集合即可，而无需对DDL事务再次解析，能够节约计算设备的计算资源。

在另一些实施例中，计算设备在解析DDL事务的每一项操作时，无需执行上述记录操作解析信息，也无需维护操作解析信息集合，只需要对每一项操作再次进行解析，即可根据解析得到的数据对象和操作类型，在DDL操作表中创建一条对应的DDL操作记录，从而节约计算设备的存储开销。

在一些实施例中，该DDL操作表是一种用于记录数据库中的数据对象（如数据表、索引等）的版本变化所对应的DDL操作的数据字典表，示意性地，DDL操作表的表定义如下：

CREATE TABLE DDL_OPERATOR (定义一张用来记录数据库中各个数据对象在不同版本之间需要针对数据记录进行的DDL操作

ID BIGINT PRIMARY,主键列

OBJ_ID BIGINT, 用来定义本DDL操作对应的实际数据库对象的对象标识objectid

OBJ_TYPE INT, 用来定义相关DDL操作对应的实际数据库对象的对象类型

SCHEMA_VERSION INT, 用来定义相关DDL操作对应的实际数据库对象的对象版本

OP_TYPE INT, 本DDL操作的操作类型，可对应于数据库内核在处理逻辑上的不同枚举值

OP_OBJECT JSON)； 本DDL操作的操作数据结构，每一种操作类型都具有对应的操作数据结构，用来作为后续操作处理函数的输入信息。

需要说明的是，在DDL操作表中存储的每一行DDL操作记录，都对应于针对每一个数据列进行的一种类型的DDL操作。

在上述DDL操作表中，由于表定义中本身就包含了SCHEMA_VERSION字段，即针对DDL事务所操作的数据表和索引等数据对象，都在DDL操作表中增加SCHEMA_VERSION字段，用来显示当前的数据表、索引或者数据列等数据对象的版本号，从而用来标识数据对象的最新的对象版本。

示意性地，下述代码示出了一种可能的DDL操作表：

mysql>select * from information_schema.tables where table_name=‘t1’\G

*********************** 1. row ************************

TABLE_CATALOG: def

TABLE_SCHEMA: test

TABLE_NAME: t1

TABLE_TYPE: BASE TABLE

ENGINE: ROCKSDB

VERSION: 10

ROW_FORMAT: Fixed

TABLE_ROWS: 0

AVG_ROW_LENGTH: 0

DATA_LENGTH: 0

MAX_DATA_LENGTH: 0

INDEX_LENGTH: 0

DATA_FREE: 0

AUTO_INCREMENT: NULL

CREATE_TIME: 2021-03-23 09:41:33

UPDATE_TIME: NULL

CHECK_TIME: NULL

TABLE_COLLATION: utf8_general_ci

CHECKSUM: NULL

CREATE_OPTIONS:

TINDEX_ID: 10001

SCHEMA_VERSION: 1//此处记录数据对象的版本号

SCHEMA_STATUS: 88

AUTOINC_TINDEX_ID: 0

HIDDEN_PK_AUTOINC_TINDEX_ID: 0

TABLE_COMMENT:

EXTRA_INF0: {“version”:1, “create_ts”:0}

1 row in set (0.00 sec)

203、计算设备在该数据表的数据字典中对该数据对象的定义执行该操作后，提交该DDL事务。

在一些实施例中，计算设备确定该DDL事务所操作的数据对象所关联的数据表，访问该数据表的数据字典，在该数据字典中对该DDL事务所操作的数据对象的定义执行对应的操作，并在对数据对象的定义执行该操作完毕后，即可提交该DDL事务，而无需等待对数据表中实际存储的该数据对象进行对应的操作，因此能够大大提升DDL事务的执行性能。需要说明的是，虽然在DDL事务的执行和提交期间，无需对数据表中实际存储的该数据对象进行对应的操作，但为了保证用户业务能够访问到数据记录的正确版本，需要在DML事务的执行期间，根据DDL操作表中的各条DDL操作记录，对本DML事务所访问的数据记录进行字段解析和版本转换，即将对数据记录的版本转换工作异步到了用户业务实际要访问本条数据记录的阶段，并且对用户业务的影响也能够忽略不计。

示意性地，DDL事务为修改数据表A中数据列c1的列类型，那么只需要在DDL操作表中记录下来对数据表A中数据列c1的列类型的DDL操作记录，然后访问数据表A的数据字典，在该数据字典中对数据列c1的列类型的定义进行修改，而不需要扫描数据表A的所有数据记录并对每条数据记录中与数据列c1对应的字段数据修改数据类型，这一对实际的数据记录进行操作的过程异步到某一用户业务需要访问数据表A中的某一条数据记录N时，对数据记录N中与数据列c1对应的字段数据修改数据类型之后，再将最新版本的数据记录N返回给用户业务。

上述所有可选技术方案，能够采用任意结合形成本公开的可选实施例，在此不再一一赘述。

本申请实施例提供的方法，通过对DDL事务在DDL操作表中创建对应的DDL操作记录，使得DDL事务在完成对数据字典中存储的数据对象的定义的操作之后，无需等待在数据表中数据记录执行相关操作，即可提交DDL事务，这一在线DDL方式无需对数据表进行加锁，不会阻塞用户业务，并且能够适用于各种不同操作类型的DDL事务，从而提供了一种针对各类不同操作类型的DDL事务的通用在线DDL执行方式，能够提升数据库系统的事务执行性能。

进一步地，由于在数据字典中完成对数据对象定义的修改之后，即可提交DDL事务，无需等待在数据表中数据记录执行相关操作，换言之，对数据表中数据记录的相关操作可异步到用户业务访问到数据记录时进行，只需要根据DDL操作表中存储的各个DDL操作记录以进行字段解析和版本转换即可，因此，在DDL事务执行期间无需扫描整个数据表中所有数据记录并执行相关操作，能够大大节约DDL事务的执行耗时，且无需开辟一张临时表来复制原表中的数据记录，即不需要额外开辟与原表相同大小的存储空间才能够执行DDL事务，这在用户大表的场景下能够大大节约计算设备的存储开销。

在上述实施例中，简单介绍了针对各类不同操作类型的DDL事务的通用在线DDL框架，在本申请实施例中，将对该通用在线DDL框架中的各项实施细节进行说明。

由于通用在线DDL框架下，提供对DDL事务遭遇异常时的异常处理机制，比如，技术人员在某种操作类型的DDL事务下挂载异常数据函数，从而自动调用异常处理函数来进行异常修复，或者，还支持技术人员手动处理发生异常的数据记录，这些异常处理机制的实现离不开对DDL语句的扩展。以下，对通用在线DDL框架下DDL语句的扩展方式进行说明，以MySQL语法为例。

（1）手动处理异常或自动处理异常

ALTER TABLE tbl_name

[alter_option [, alter_option] ...]

[partition_options][，ON EXCEPTION {Manual ｜User specific handlerfunc}]

在上述DDL语句中，增加了一个异常处理参数ON EXCEPTION 用来定义DDL语句的异常处理机制，即在需要修改列类型且数据列上面定义了唯一性约束（主键或者二级索引）的情况下，如果发生了数据冲突，DDL语句应该如何进行异常处理。针对异常处理参数ONEXCEPTION，增加了两个语法项：Manual（手动）选项和User specific handler func（自动）选项。

（1.1）Manual：如果指定Manual选项，当执行DDL语句进行列类型修改过程遇到数据冲突，会停止DDL语句对应的DDL事务，等待技术人员手动处理完异常（以上面的实施例中varchar字符串转到int整型的例子，DDL进程返回发送数据冲突的数据记录，等待技术人员手动修改数据记录以解决数据冲突后，可继续启动DDL事务执行）。

（1.2）User specific handler func：如果指定User specific handler func选项，需要技术人员自定义冲突自动处理方式，比如技术人员通过实现一个异常处理函数，并在DDL语句中指定该异常处理函数的函数名，在发生列类型转换数据冲突的时候，会自动调用该异常处理函数来解决发生的数据冲突。例如，该异常数据函数可采用数据库中的技术人员预先定义的函数。

（2）Manual模式下的跳转参数

在选中Manual选项，即开启手动处理异常模式下，扩展SELECT和UPDATE 的SQL语句语法，即增加一个跳转参数-skip，用来方便技术人员手动处理数据转换异常。

例如，使用select * from T1 where Row_id = xxx -skip;

在对数据列进行变更过程中发生转换异常（如列类型转换不兼容）时，技术人员根据返回的数据记录的记录ID（Identification，标识），使用update T1 set C1=手动修改值where row_id = xxx -skip;语句来手动处理本条数据记录的数据冲突。

当处理到的SQL语句中携带-skip参数时，当数据库引擎读取到一条旧版本的数据记录时，会按照数据记录的版本来解析字段，并利用DDL操作表来更新为最新版本，因此不会发生类型转换异常，同时update能够完成列类型的手动转换。

由于通用在线DDL框架下，对每个DDL语句都会形成一个DDL事务，对每个DDL事务都会维护一个DDL事务的跟踪信息，这一跟踪信息用于跟踪DDL事务的实际执行状态，比如，当DDL事务涉及到修改数据列的列类型，且数据列上建立了关联的二级索引，那么需要将该跟踪信息设置为未完成状态后，才能够提交DDL事务，DDL事务虽然完成了提交，但是后续相关的索引修改事务尚未完成之前，是不能将跟踪信息从未完成状态修改为已完成状态的，这是为了保证数据记录与二级索引之间的数据一致性，因此维护DDL事务的跟踪信息对于通用在线DDL框架下数据一致性的保障是至关重要的。以下，对通用在线DDL框架下增加的4条命令进行说明。

（A）用来获取每一个DDL事务的事务ID

SHOW ACTIVE DDL_JOB;

上述命令用来显示当前活跃的DDL事务的事务ID，因为每一个DDL事务都会对应一个后台的跟踪信息，该跟踪信息用来跟踪DDL事务的执行情况，在发生意外时可以对该DDL事务对应的DDL语句进行恢复。

以下，为使用上述命令查询当前活跃的DDL事务的事务ID的一种运行结构的示例性说明：

MySQL [test]>show active ddl_job;

+----------+----------------------------------------------

+----------------------------------------+

|Job_id|Statement｜Issue time

+----------+----------------------------------------------

+----------------------------------------+

|10001|ALTER TABLE ADD COLUMN NEW_C INT AFTER c_a;｜2021-07-28 12:30:56

+----------+----------------------------------------------

+----------------------------------------+1 rowinset(0.00 sec)

（B）用来触发DDL事务中断后继续执行

DDL_JOB job_id CONTINUE EXECUTION;

上述命令是用于提供DDL事务中断后，不回滚整个DDL事务，而是从中断处继续执行的功能。当技术人员设定异常处理参数为ON EXCEPTION Manual的时候，如果遇到唯一索引发生数据转换冲突的问题，能够暂停DDL事务对当前数据记录的转换工作，向技术人员返回冲突相关的数据记录，等待技术人员手动更新数据记录以消除冲突之后，从中断的数据记录所在的数据块block开始继续执行。

以下，为使用上述命令触发DDL事务从中断处继续执行的一种示例性说明：

MySQL [test]>DDL_JOB 10001 CONTINUE EXECUTION;0 rowinset(0.00 sec)

（C）用来设置默认值的显示方式

SET DEFAULT VALUE SHOW MODE 0 | 1;

上述命令是用来给技术人员设定数据记录中某一字段数据的默认值的显示方式，使用两种可选的取值：取值为0，则沿用主流的默认值显示方式，即所有未赋值且定义了默认值的数据列所对应的字段数据，都显示最新的默认值；取值为1，则使用数据记录的当前版本对应的默认值版本来进行显示，即能够支持查询与数据记录当前版本对应的历史默认值，而非一律显示最新的默认值。

以下，为使用上述命令选择取值为0时，显示最新的默认值的一种示例性说明：

MySQL [test]>SET DEFAULT VALUE SHOW MODE 0;

0 rowinset(0.00 sec)

（D）用来显示当前数据库系统所采用的默认值显示方式

SHOW DEFAULT VALUE SHOW MODE;

上述命令是用来显示当前数据库系统所采用的默认值显示方式，即方便技术人员查询当前是采用最新的默认值显示方式，还是采用与数据记录的当前版本对应的默认值版本显示方式。

以下，为使用上述命令查看当前数据库系统所采用的默认值显示方式的一种示例性说明：

+---------------------------+---------------------------------------

--------------------------------+

|DEFAULT VALUE SHOW MODE ｜

Definition+---------------------------+------------------------------

-----------------------------------------+

|1｜Base on record version to determine what default value should be used.

+-------------------------+------------------------------------------

-------------------------------+

1 rowinset(0.00 sec)

由于通用在线DDL框架下，假设DDL事务涉及修改数据列的列类型，并且在数据列上建立了二级索引，那么还需要对二级索引中的相关数据一并修改，避免通过二级索引查询到过时的数据，在修改二级索引的过程中，需要将数据表标记为检查（checking）状态，并将索引标记为仅允许写入（write only）状态。

假设在某一时刻切换了查询数据表和索引的状态，可通过如下代码来显示数据表在当前状态下命令结果的输出变化：MySQL [test]>showcreatetablet1;

+-------+-----------------------------------------------------------

--------------------------------+

|Table|CreateTable|

+-------+----------------------------------------------------------

---------------------------------+

| t1 |CREATETABLE`t1` ( /* checking */

`a`intNOTNULL,

`b`intDEFAULTNULL,

PRIMARYKEY(`a`),

KEY`idx1` (`b`) /* write only */

) ENGINE=InnoDBDEFAULTCHARSET=utf8mb3 |

+-------+------------------------------------------------------------

-------------------------------+

1 rowinset(0.00 sec)

在上述过程中，通过对数据表增加一个checking检查状态，checking检查状态只是用来说明目前DDL事务虽然已经返回执行成功（即DDL事务已提交），但是由于索引后台变更数据类型正在发生，导致相关索引不能被优化器选中来查询数据，可能会导致相关查询执行变慢，换言之，checking检查状态只会发生在变更列类型且数据列在唯一索引上的情况，这种情况下不但要修改索引也需要同步处理变更列类型，checking检查状态表明当前数据表或索引处于DDL语句异步处理数据记录的阶段。

在通用在线DDL框架下，数据库中的每一张数据表都用来管理一组数据集合，这张数据表的元信息都存放在该数据表的数据字典中，以MySQL数据字典为例进行说明，假设针对如下代码所示的一张数据表，以该数据表的表定义为实例，说明该数据表相关的元信息的存储情况：

mySQL>show create table t1;

+-------+-----------------------------------------------------------

------+

| Table | Create Table |

+-------+-----------------------------------------------------------

------+

| t1 | CREATE TABLE ‘t1’ (

‘a’ int(11) NOT NULL,

‘b’ int(11) DEFAULT NULL,

‘c’ int(11) DEFAULT NULL,

PRIMARY KEY (‘a’) /* PUBLIC */,

KEY ‘idx’ (‘c’) /* PUBLIC */

) ENGINE=ROCKSDB DEFAULT CHARSET=utf8 |

针对上述数据表，该数据表中各个数据对象在数据字典中的表现形式可如表1所示。

表1

上述表1中说明了数据库中各个数据对象在数据字典中的表现形式，在本申请实施例中，数据字典中对每一个数据对象增加一个版本号，来描述该数据对象是在哪个版本引入的（或者说在哪个版本修改的）。对于数据库中的所有元素，后续涉及需要进行版本变更的，都能够通过增加一个版本号字段来进行版本变更的统一管理。

在上述数据字典中录入数据对象的版本号的基础上，还需要针对数据表中存储的数据记录也录入各自当前的版本号，在一些实施例中，如果数据库系统支持多种默认值显示方式，那么对每条数据记录需要记录两个版本号：记录插入版本号和记录版本号，该记录插入版本号是指向数据表中插入该条数据记录时所处的版本号（相当于数据记录的起始版本号），该记录版本号是指该条数据记录当前所处的版本号（但不一定是最新版本），以便于根据记录插入版本号，确定出在将该数据记录插入数据表时为该数据记录匹配对应的默认值。在另一些实施例中，如果数据库系统不支持多种默认值显示方式，即，只支持显示最新的默认值版本，那么对每条数据记录只需要存储该记录版本号即可，而无需存储该记录插入版本号，本申请实施例不对此进行具体限定。

有鉴于此，对数据表中存储的数据记录的存储格式进行改进，图3是本申请实施例提供的一种数据记录的存储格式的原理性示意图，如300所示，分别示出了通用在线DDL框架下数据记录的存储格式和二级索引的存储格式。

对数据记录来说，不但需要存储包含数据表中定义记录的主键与所有字段的值信息所构成的记录字符串，而且还需要存储记录插入版本号和记录版本号，用来表明数据记录中各个字段（数据列）对应的应该是哪个版本的表定义组成的数据记录的存储数据。可选地，该数据记录以Key-Value结构存储，或者该数据记录以heap表结构存储，本申请实施例不对该数据记录的存储结构进行具体限定。

对二级索引来说，通常索引结构都定义为Key-Value键值对的结构存储（其中，Value没有存放数据，也可能存放一些特殊信息），二级索引中也需要存储两个版本号：索引插入版本号和索引版本号，该索引插入版本号是指在数据库中建立该条二级索引记录时所处的版本号（相当于二级索引的起始版本号），该索引版本号是指该条二级索引记录当前所处的版本号（但不一定是最新版本）。

在上述过程中，通过对数据记录和二级索引记录分别都记录两个版本号，使得当数据记录或二级索引记录被读取时，记录版本号或索引版本号能够准确地指示应该使用哪个版本的表定义来解析得到正确的最新版本，并且，当数据记录或二级索引记录被读取时，可使用当前事务持有的数据表（table）最新版本的表定义，拼出数据记录的存储数据并更新相应的记录版本号，同时对数据记录关联的二级索引记录也进行修改后更新相应的索引版本号，此外，通过记录插入版本号或索引插入版本号，能够确定出当前数据记录或二级索引记录是在哪个版本插入到数据库中的，用来确定数据记录或二级索引记录进入数据库系统的时间，以匹配对应的默认值。

在通用在线DDL框架下，由于需要根据DDL操作表中记录的各条DDL操作记录，来对非最新版本的数据记录进行解析，并转换为对应的最新版本的数据记录，因此每一条DDL操作记录都能够对应到一个数据表的DDL操作分解出来的对应数据列的操作和描述，通过将DDL操作表和数据表一起加载到内存中进行缓存，当读取到旧版本（即非最新版本）的数据记录时，采用相应的信息（非必需）来对数据记录进行记录解析和版本转换，即将数据记录从旧的记录格式转换为新的记录格式。

有鉴于此，需要对DDL事务涉及的各种不同操作类型分配不同的op_type枚举值，以确保每种操作类型和一种op_type枚举值一一对应，从而通过op_type枚举值能够唯一标识出一种操作类型。

以下，基于上述实施例所列出的DDL事务涉及的各种操作类型，给出一种对op_type枚举值的定义方式的示例性说明：

enum op_type = {

add_column, /* Add column（增加列）*/

drop_column, /* Drop column（删除列）*/

change_column, /* Change column position（修改列位置）*/

set_default, /* Change column defalut（修改列默认值）*/

expend_type, /* Change column type compatible，修改列类型且数据类型对应的长度与范围在DDL执行前后会扩大，例如 int ->bigint, char(5) ->char(10) */

shirnk_type， /* Change column type compatible，修改列类型且数据类型对应的长度与范围在DDL执行前后会缩小，指与上面例子反向的DDL情况 */

chg_type_no_idx， /* Change column type not compatible，修改列类型但数据类型不兼容，修改类型的数据列不涉及唯一二级索引，但可能有二级索引定义 */

chg_type_idx, /* Change column type not compatible，修改列类型但数据类型不兼容，修改类型的数据列涉及唯一二级索引 */

}

上述op_type枚举值定义了通用在线DDL框架所支持的在线DDL操作，如果后续涉及到新增其他DDL操作的在线模式（例如主键变更），则可为新增的DDL操作分配新的op_type枚举值。

进一步地，对于DDL操作表中的每一条DDL操作记录，尤其是修改列位置和修改列类型可能会在同一个DDL语句中出现。例如，在同一个DDL语句中，涉及修改数据表T1的C1和C2两个数据列的列类型，同时互换C1和C2两个数据列的列位置，在这种情况下将上述DDL语句解析到DDL操作表时，会在DDL操作表中新插入4条DDL操作记录：2条关于数据列C1和C2的列位置变化的DDL操作记录，以及2条关于数据列C1和C2修改列类型的DDL操作记录。

针对上述列出各种op_type枚举值，可对各种op_type枚举值所涉及操作的数据对象分配不同的op_object枚举值，即op_object枚举值用于标识各个DDL操作所涉及的数据对象所对应的数据结构。

以下，DDL事务涉及的各种op_type枚举值，给出一种对op_object枚举值的定义方式的示例性说明：

struct add_column {

adding_version int; /* 新增数据列对应的表版本 */

adding_pos int; /* 用来描述增加数据列的列位置 */

}

struct drop_column {

drop_version int; /* 删除数据列对应的表版本*/

drop_pos int; /* 删除数据列所在记录字段位置 */

drop_type string; /* 删除数据列的列类型 */

drop_length int; /* 删除数据列的类型长度属性 */

}

struct change_column {

change_version int;

is_change_pos bool; /* 是否有修改列位置 */

orig_pos int; /* 数据列的原始位置 */

target_pos int; /* 数据列移动的目标位置 */

is_change_type bool; /* 是否数据列有类型修改。 */

orig_type enum type; /* 原始数据列类型，数据库支持的列类型 */

target_type enum type; /* 目标数据列类型，数据库支持的列类型 */

is_rename bool; /* 是否数据列有改名字 */

orig_name string /* 记录修改前的列名 */

handler func_ptr /* 如果技术人员指定自动调用的异常处理函数，这里记录函数指针 */

}

struct change_default {

change_version int;

col_pos int; /* 数据列的列位置 */

orig_default string; /* 使用字符串来表示各种数据类型值 */

}

在上述提供的通用在线DDL框架的基础上，本申请实施例以某一DDL事务所操作的数据对象为数据表中的数据列为例，介绍此类DDL事务的在线DDL执行流程，下面进行说明：

图4是本申请实施例提供的一种事务执行方法的流程图，本申请实施例适用于单机数据库系统、集群数据库系统、分布式数据库系统、计算存储分离的云原生数据库架构、区块链系统等，在此不做具体限定。如图4所示，该实施例由数据库系统中的任一计算设备执行，该实施例包括下述步骤：

401、计算设备响应于DDL事务，在该DDL事务所操作的数据对象与数据表中的数据列相关联的情况下，确定该操作的操作类型。

上述步骤401与上述步骤201类似，这里不做赘述。

402、计算设备在解析该DDL事务所涉及的每一项操作的操作类型时，对该操作所涉及的每一个数据对象生成对应的操作解析信息。

在一些实施例中，计算设备在上述步骤201中解析该DDL事务所涉及的每一项操作的操作类型时，对该操作所涉及的每一个数据对象，执行上述步骤402以生成对应的操作解析信息，由于该DDL事务可能涉及到一项或多项操作，而每一项操作可能涉及到一个或多个数据对象，因此，执行下述步骤403以将该DDL事务的各项操作所涉及的各个数据对象的该操作解析信息，存储到操作解析信息集合中。

403、计算设备将该DDL事务的各项操作所涉及的各个数据对象的该操作解析信息，存储到操作解析信息集合中。

在上述过程中，通过在解析DDL事务的每一项操作时，记录其对应的操作解析信息并录入操作解析信息集合，从而在创建DDL操作记录时直接访问该操作解析信息集合即可，而无需对DDL事务再次解析，能够节约计算设备的计算资源。

在另一些实施例中，计算设备在解析DDL事务的每一项操作时，无需执行上述记录操作解析信息，也无需维护操作解析信息集合，只需要对每一项操作再次进行解析，即可根据解析得到的数据对象和操作类型，在DDL操作表中创建一条对应的DDL操作记录，从而节约计算设备的存储开销。

404、计算设备在该数据表的DDL操作表中，为该操作解析信息集合中的每一个操作解析信息创建一条对应的DDL操作记录，该DDL操作表用于建立该数据表中数据记录的不同版本之间的映射关系。

在一些实施例中，该DDL操作表是一种用于记录数据库中的数据对象（如数据表、索引等）的版本变化所对应的DDL操作的数据字典表，DDL操作表的表定义与上述步骤202给出的示例类似，这里不做赘述。

在上述步骤402-404中，计算设备基于该操作类型，在该数据表的DDL操作表中为该操作创建对应的DDL操作记录，其中，在DDL操作表中存储的每一行DDL操作记录，都对应于针对每一个数据列进行的一种类型的DDL操作。

在本申请实施例中，对该操作解析信息集合中的每一个操作解析信息，由于需要对该操作解析信息创建对应的DDL操作记录，在该操作解析信息所对应的数据对象为数据列的情况下，由于对DDL操作所涉及的每个数据列都会记录对应的操作解析信息，因此，对每一个数据列的操作解析信息，根据对该数据列所执行的DDL操作的操作类型（如增加列、删除列、修改列）的不同，可划分为如下几种情况进行分类讨论：

404-A、在该操作解析信息对应的操作类型为增加列的情况下，生成增加该数据列的DDL操作记录。

在上述过程中，如果DDL操作记录中涉及的操作类型为增加列，此时可直接按照该操作解析信息，更新DDL操作表，即生成增加数据列的DDL操作记录，并在该DDL操作表中插入该增加数据列的DDL操作记录，然后跳转至下述步骤405-406，而无需对数据表、索引或者DDL事务的跟踪信息进行任何处理。

404-B、在该操作解析信息对应的操作类型为删除列的情况下，生成删除该数据列的DDL操作记录。

在上述过程中，如果DDL操作记录中涉及的操作类型为删除列，此时可直接按照该操作解析信息，更新DDL操作表，即生成删除数据列的DDL操作记录，并在该DDL操作表中插入该删除数据列的DDL操作记录，然后跳转至下述步骤405-406，而无需对数据表、索引或者DDL事务的跟踪信息进行任何处理。

404-C、在该操作解析信息对应的操作类型为修改列的情况下，若该数据列不具有关联的索引或者该操作类型不涉及修改该数据列的列类型，生成修改该数据列的DDL操作记录。

在上述过程中，如果DDL操作记录中涉及的操作类型为修改列，但是并不涉及到修改数据列的列类型（比如修改列名、修改默认值等），或者该数据列不具有关联的索引（比如修改列类型但数据列上并未建立唯一索引），说明只需要更新DDL操作表而无需同步建立索引修改事务，因此同理可直接按照该操作解析信息，更新DDL操作表，即生成修改数据列的DDL操作记录，并在该DDL操作表中插入该修改数据列的DDL操作记录，然后跳转至下述步骤405-406，而无需对数据表、索引或者DDL事务的跟踪信息进行任何处理。

404-D、在该操作解析信息对应的操作类型为修改列的情况下，若该数据列具有关联的索引并且该操作类型涉及修改该数据列的列类型，将该索引标记为仅允许写入状态，将该数据列所在的数据表标记为检查状态，将该DDL事务的跟踪信息置为未完成状态；生成修改该数据列的DDL操作记录。

在上述过程中，如果DDL操作记录中涉及的操作类型为修改列，并且DDL事务涉及到修改数据列的列类型，且该数据列具有关联的索引，此时不但需要更新DDL操作表，还需要同步建立索引修改事务，以保证数据记录和关联的二级索引记录都需要更新到最新版本，防止数据库系统出现数据记录和二级索引记录之间数据不一致的情况，因此，此时需要将索引标记为仅允许写入（write only）状态，在仅允许写入（write only）状态下，该索引是不能被优化选中来查询数据的（后果是可能导致相关查询事务的执行变慢），并且将数据表标记为检查（checking）状态，在检查（checking）状态下，DDL事务是能够通过下述步骤405-406进行提交（以返回执行成功）的，但是后台还需要异步开启索引修改事务，以变更索引中的数据类型，因此数据表需要以检查（checking）状态来标识这种情况，即检查（checking）状态只会发生在变更列类型且数据列在唯一索引上的情况，这种情况下不但要修改索引也需要同步处理变更列类型，检查（checking）状态表明当前数据表或索引处于DDL语句异步处理数据记录的阶段。此外，由于在通用在线DDL框架下，会为每个DDL事务都维护一个DDL事务的跟踪信息，因此也需要将跟踪信息置为未完成状态，代表虽然本DDL事务已经提交，但后台关联的索引修改事务尚未完成，因此DDL事务实际应该是未完成状态。在将索引标记为仅允许写入（write only）状态、将数据表标记为检查（checking）状态、将跟踪信息置为未完成状态之后，即可按照该操作解析信息，更新DDL操作表，即生成修改数据列的DDL操作记录，并在该DDL操作表中插入该修改数据列的DDL操作记录，然后跳转至下述步骤405-406。在下一个实施例中，将对索引修改事务的执行方式进行详细说明，这里不再赘述。

405、计算设备在该数据表的数据字典中对该数据对象的定义执行该操作。

在一些实施例中，计算设备确定该DDL事务所操作的数据对象所关联的数据表，访问该数据表的数据字典，在该数据字典中对该DDL事务所操作的数据对象的定义执行对应的操作，并在对数据对象的定义执行该操作完毕后，即可通过下述步骤406来提交该DDL事务，而无需等待对数据表中实际存储的该数据对象进行对应的操作，因此能够大大提升DDL事务的执行性能。

需要说明的是，虽然在DDL事务的执行和提交期间，无需对数据表中实际存储的该数据对象进行对应的操作，但为了保证用户业务能够访问到数据记录的正确版本，需要在DML事务的执行期间，根据DDL操作表中的各条DDL操作记录，对本DML事务所访问的数据记录进行字段解析和版本转换，即将对数据记录的版本转换工作异步到了用户业务实际要访问本条数据记录的阶段，并且对用户业务的影响也能够忽略不计。

示意性地，DDL事务为修改数据表A中数据列c1的列类型，那么只需要在DDL操作表中记录下来对数据表A中数据列c1的列类型的DDL操作记录，然后访问数据表A的数据字典，在该数据字典中对数据列c1的列类型的定义进行修改，而不需要扫描数据表A的所有数据记录并对每条数据记录中与数据列c1对应的字段数据修改数据类型，这一对实际的数据记录进行操作的过程异步到某一用户业务需要访问数据表A中的某一条数据记录N时，对数据记录N中与数据列c1对应的字段数据修改数据类型之后，再将最新版本的数据记录N返回给用户业务。

406、计算设备提交该DDL事务。

在上述步骤406中，计算设备提交DDL事务，如果涉及到上述404-D的情况，需要在提交DDL事务之后，异步开启索引修改事务，当索引修改事务也执行完毕之后，才会将索引从仅允许写入（write only）状态修改为发布（public）状态，同时将数据表从检查（checking）状态修改为发布（public）状态，再将DDL事务的跟踪信息从未完成状态修改为已完成状态。

上述所有可选技术方案，能够采用任意结合形成本公开的可选实施例，在此不再一一赘述。

本申请实施例提供的方法，通过对DDL事务在DDL操作表中创建对应的DDL操作记录，使得DDL事务在完成对数据字典中存储的数据对象的定义的操作之后，无需等待在数据表中数据记录执行相关操作，即可提交DDL事务，这一在线DDL方式无需对数据表进行加锁，不会阻塞用户业务，并且能够适用于各种不同操作类型的DDL事务，从而提供了一种针对各类不同操作类型的DDL事务的通用在线DDL执行方式，能够提升数据库系统的事务执行性能。

进一步地，由于在数据字典中完成对数据对象定义的修改之后，即可提交DDL事务，无需等待在数据表中数据记录执行相关操作，换言之，对数据表中数据记录的相关操作可异步到用户业务访问到数据记录时进行，只需要根据DDL操作表中存储的各个DDL操作记录以进行字段解析和版本转换即可，因此，在DDL事务执行期间无需扫描整个数据表中所有数据记录并执行相关操作，能够大大节约DDL事务的执行耗时，且无需开辟一张临时表来复制原表中的数据记录，即不需要额外开辟与原表相同大小的存储空间才能够执行DDL事务，这在用户大表的场景下能够大大节约计算设备的存储开销。

在上述实施例中，如果涉及到上述404-D（即DDL事务涉及修改列类型，且数据列具有关联的索引）的情况，需要在提交DDL事务之后，异步开启索引修改事务，在本申请实施例中，将对索引修改事务的执行流程进行详细说明。

图5是本申请实施例提供的一种索引修改事务的执行流程图，本申请实施例适用于单机数据库系统、集群数据库系统、分布式数据库系统、计算存储分离的云原生数据库架构、区块链系统等，在此不做具体限定。如图5所示，该实施例由数据库系统中的任一计算设备执行，该实施例包括下述步骤：

501、计算设备对DDL事务操作的数据列所关联的索引，启动索引修改事务。

在一些实施例中，该索引修改事务是在将索引标记为仅允许写入（write only）状态、将数据表标记为检查（checking）状态、将DDL事务的跟踪信息置为未完成状态之后才开启的。

可选地，在将索引标记为仅允许写入（write only）状态之后，即可为该索引修改事务获取对应的事务ID（或者事务快照）。对单机数据库来说，该事务ID可为本地时间戳，对分布式数据库来说，该事务ID可为全局时间戳。

在一些实施例中，计算设备需要在获取相应权限之后，才能修改索引的状态并申请事务ID，从而能够提高DDL事务的安全性。

需要说明的是，在将索引标记为仅允许写入（write only）状态之后，后续对应该数据列所在数据表的所有修改都会同步到索引中，并且在标记仅允许写入（write only）状态完毕后，如果此时数据库系统中还存在未提交的、对于该数据表的修改事务，这些修改事务都会被回滚掉，或者进入等待队列中暂停处理（并在索引修改事务提交后排队执行），才能够相关修改事务能够访问到最新版本的数据记录和二级索引。

502、计算设备响应于该索引修改事务，修改该数据列所在的数据表中的每一条数据记录和每一条数据记录所关联的索引记录。

在一些实施例中，计算设备扫描该数据列所在数据表的全表数据，从而对该数据表中的每一条数据记录进行对应的修改（例如，修改数据列所对应字段数据的数据类型，即修改列类型），同时提取对应的修改后的字段数据用来创建二级索引的Key（假设二级索引以Key-Value格式存储）。

在一些实施例中，在扫描全表数据时，将该数据表中的索引数据记录以数据块（block）为单位进行划分和扫描，并在一个动态数组中登记已扫描完毕的各个block的block ID，以便于当发送数据冲突或进程崩溃等异常时，能够在异常修复之后，从已记录的扫描完毕的最后一个block的下一个block来继续执行该索引修改事务，而无需将整个索引修改事务进行回滚或重做，能够有利于提高索引修改事务的执行成功率，优化了数据库系统的资源利用率。

在一些实施例中，在扫描全表数据时，计算设备可使用单个进程对所有block串行处理，或者，使用多个进程对所有block划分为多个并行任务后进行并行处理，本申请实施例不对选择串行处理还是并行处理进行具体限定。

在一些实施例中，在提取对应的修改后的字段数据之后，使用托马斯写规则将二级索引的Key写入索引结构中，因此如果两者之间有冲突的话，比较用户业务事务的修改与二级索引变更事务（即上述步骤501启动的索引修改事务）修改的最终得到的记录版本号，在版本号随着时间的推移呈单调递增的情况下，选择保留最大的记录版本号即可，反之，在版本号随着时间的推移呈单调递减的情况下，选择保留最小的记录版本号即可，总而言之，如果两者得到的记录版本号不一致，则选择保留最新修改得到的记录版本号。如果两者得到的记录版本号一样，则只需要保留后续用户业务事务对于表对应数据的修改即可（即保证将后续任何对数据表的修改同步到索引中）。

在一些实施例中，对该数据表中存储的每一条数据记录，如果该数据记录本身已经是最新版本，那么跳过本条数据记录，继续扫描下一条数据记录，如果该数据记录并非最新版本，则需要将该数据记录转换为最新版本之后，将该最新版本的数据记录写回该数据表。进一步地，在该数据记录所关联的索引记录中，写入该最新版本的数据记录中与该索引对应的字段数据，以覆盖已有的同一字段数据。

在上述过程中，可知对于索引修改事务来说，需要先将数据表中对应的每条数据记录更新到最新版本（如果本身已经是最新版本，则无需处理，如果本身并非最新版本，则需要转换到最新版本后写回数据表），即保证后续事务读取到的是已经转换成最新版本的数据记录，同时在关联的索引记录中也修改为最新版本的数据记录，保证通过二级索引查询到的数据记录也是最新版本，即保证了数据一致性。

在一些实施例中，在将该数据记录转换为最新版本时，计算设备可执行如下操作：查询该数据表的DDL操作表，得到该数据记录从当前版本到该最新版本之间发生的至少一条DDL操作记录；基于该至少一条DDL操作记录，生成从该当前版本到该最新版本的字段映射关系；基于该字段映射关系，对该数据记录的各个字段数据进行映射操作，得到该最新版本的数据记录。

由于本身数据记录的存储格式中会存放该数据记录的记录版本号（即当前版本的版本号），因此，基于该数据记录的存储结构中的记录版本号，可确定该数据记录的当前版本的版本号，在版本号随着时间的推移呈单调递增的情况下，则将当前时刻下该数据表的表定义的最大版本号确定为最新版本的版本号，反之，在版本号随着时间的推移呈单调递减的情况下，则将当前时刻下该数据表的表定义的最小版本号确定为最新版本的版本号，在本申请实施例中，如无特别说明，均以版本号随着时间的推移呈单调递增的情况进行示例性说明。

接着，基于该当前版本的版本号和该最新版本的版本号，在该DDL操作表中查询该数据记录从该当前版本的版本号到最新版本的版本号之间发生的该至少一条DDL操作记录，由于DDL操作记录中本身会记录所操作的数据对象和该数据对象的版本号，只需要遍历数据对象为该索引修改事务所对应的数据表的各条DDL操作记录，并获取该数据对象的版本号大于或等于当前版本的版本号且小于或等于最新版本的版本号的所有DDL操作记录，即可得到该数据记录从当前版本到该最新版本之间发生的该至少一条DDL操作记录。需要说明的是，在当前版本的版本号等于最新版本的版本号时，代表数据记录本身就是最新版本，因此在DDL操作表中不会记载相关的DDL操作记录；在当前版本的版本号小于最新版本的版本号时，则包含至少一条DDL操作记录；在当前版本的版本号大于最新版本的版本号时，说明由于更新延迟等原因导致计算设备本地的表定义比较旧，需要对本地的表定义进行更新。

在一些实施例中，由于每条DDL操作记录中均会记录对该索引修改事务所对应的数据表执行的DDL操作，因此，该至少一条操作记录实际反映的是数据记录从当前版本到最新版本中每一次版本变更所需要进行DDL操作，可选地，可基于该至少一条DDL操作记录，生成该数据记录从当前版本到最新版本之间每一次版本变更时的多个字段映射关系，并基于该多个字段映射关系，对该数据记录进行多次映射操作，得到该数据记录从当前版本到最新版本之间的每个中间版本以及最终得到的最新版本，需要说明的是，在有些数据库系统中，旧的数据记录（即中间版本）会先被标记删除，再增加最新版本的数据记录，然后后续由后台选择合适的时间删除中间版本（或者将中间版本转储到分布式文件系统中），从而能够反映出数据记录所经过的多个版本的数据变更。

在一些实施例中，可基于该至少一条DDL操作记录，直接生成该数据记录从当前版本到最新版本的字段映射关系，该字段映射关系用于表示将数据记录从当前版本转换到最新版本所需要进行哪些映射操作。从而基于该字段映射关系，对该数据记录进行一次映射操作，就能够将该数据记录从当前版本转换到最新版本，从而得到最新版本的数据记录。上述过程中，由于只进行了一次映射操作就完成了当前版本到最新版本的转换任务，因此能够大大节约计算设备的计算资源。

在一些实施例中，在生成从该当前版本到该最新版本的字段映射关系之后，只需要基于该字段映射关系，对该数据记录中的各个字段数据进行对应的映射操作，即可将该数据记录从当前版本转换到最新版本，由于DDL事务的操作类型包括：增加列、删除列、修改列位置、修改列类型等，因此对字段数据的映射操作对应包括：新增字段数据、跳过字段数据、字段数据移动位置、修改字段数据类型。

在一些实施例中，在对该数据记录的各个字段数据进行映射操作时，根据对应DDL操作记录中所对应的操作类型的不同，该映射操作包括下述至少一项：

（Ⅰ）、若该DDL操作记录对应的操作类型包括新增列，向新增的数据列对应的字段数据中填充插入值或默认值。

可选地，在新增列的情况下，如果DDL操作记录中指定了插入值，则向新增的字段数据填充该插入值，如果DDL操作记录中未指定插入值，则向新增的字段数据中填充默认值，需要说明的是，该默认值是指表定义的最新版本下的最新默认值。例如，新增数据列f1，如果DDL操作记录中指定了插入值为10，则对数据记录中新增的字段f1填充插入值“10”，如果DDL操作记录中未指定插入值，并且表定义在最新版本下的最新默认值为5，则对数据记录中新增的字段f1填充默认值“5”，或者，为节约存储空间，如果新增的字段f1使用默认值，则使用一个bit（位或比特）的数据表明本字段f1取默认值，并将默认值存储在数据字典中，后续如果需要解析本条数据记录，发现字段f1使用默认值，再按照内存的数据字典中缓存的默认值设置字段f1即可。

（Ⅱ）、若该DDL操作记录对应的操作类型包括删除列，跳过被删除的数据列对应的字段数据。

可选地，在删除列的情况下，由于对数据记录的转换过程，实际上是对当前版本的数据记录中的各个字段数据进行变更或重组，以映射得到最新版本的数据记录的过程，因此，在涉及删除列时，只需要跳过被删除的数据列对应的字段数据，即在生成最新版本的数据记录时不引入被删除的数据列对应的字段数据记录，这样在将最新版本的数据记录写回数据表的时候，由于最新版本的数据记录会覆盖掉当前版本的数据记录，因此自然也就实现了删除列的操作。例如，删除数据列g1，那么只需要跳过当前版本的数据记录中的字段g1即可。

（Ⅲ）、若该DDL操作记录对应的操作类型包括修改列位置，将被修改位置的数据列对应的字段数据从原始位置移动至目标位置。

可选地，在修改列位置的情况下，解析DDL操作记录，得到数据列的原始位置和目标位置，并将被修改位置的数据列对应的字段数据从原始位置移动至目标位置。例如，将数据列h1从位置7移动至位置5，则需要将当前版本的数据记录中处于位置7的字段h1移动到新的位置5（原本位置5及位置5之后除了位置7以外的字段数据则向后顺移一位）。

（Ⅳ）、若该DDL操作记录对应的操作类型包括修改列类型，对被修改列类型的数据列对应的字段数据的数据类型从原始类型转换为目标类型。

可选地，在修改列类型的情况下，解析DDL操作记录，得到数据列的原始类型和目标类型，并将被修改列类型的数据列对应的字段数据的数据类型从原始类型转换为目标类型。例如，将数据列k1从int类型修改为bigint类型，则需要将当前版本的数据记录中的字段k1中存储的int类型的数据转换为bigint类型的数据。

以下，将以对数据表T1的版本变更为例，介绍数据记录的记录解析算法，假设在创建数据表T1时，该数据表T1包含3个数据列C1、C2和C3，数据表T1的起始表版本为1，中间对数据表T1做了以下其他的DDL表定义的修改，并从表版本7开始进行举例说明，如下表2中示出了从表版本7到表版本16之间发生的涉及到增删改数据列的DDL操作记录：

表2

在上述表2中列举了对数据表T1执行的一系列DDL语句的DDL操作记录，假设当前时刻涉及到读取数据表T1中的某条数据记录，在数据表T1中实际存储的是版本6的数据记录，那么需要将数据记录从当前版本6转换到最新版本16，才能保证读取到最新版本的数据记录。下面将说明如何基于上述表2中的各条DDL操作记录，将数据记录从当前版本6转换到最新版本16。

在记录解析算法中，会先基于DDL操作表中与本条数据记录相关的各条DDL操作记录，构造一个DDL操作列表，可选地，该DDL操作列表只生成一次，后续在需要在DDL操作列表中不断增加相关DDL操作表项即可，由于不需要对每条数据记录单独生成DDL操作列表，因此能够大大节约计算设备的存储开销，提升数据库系统的处理性能。接着，基于上述DDL操作列表，生成一个基于该数据记录的当前版本6到目前表定义的最新版本16的字段映射关系，该字段映射关系可以表格形式呈现，如下表3所示：

表3

基于上表3所示的字段映射关系，能够反映出来从版本6到版本16之间表结构发生的变化，上述表3也可称为记录字段解析转换表。基于该字段映射关系，即可对数据记录的各个字段数据进行提取和转换，图6是本申请实施例提供的一种字段提取转换操作的原理性示意图，如600所示，反映了基于该字段映射关系，需要分别对版本6的数据记录中对应的每个字段数据，进行哪些有关于位置和类型的映射操作。

在一些实施例中，由于在涉及到列类型转换时，可能从原始类型到目标类型的转换过程中会发生冲突，比如列类型不兼容等问题，此时可根据DDL语句中指定的异常处理参数ON EXCEPTION来决定异常处理逻辑。可选地，该异常处理参数ON EXCEPTION包括两种取值：Manual（手动）选项和User specific handler func（自动）选项，如果该异常处理参数ON EXCEPTION命中Manual（手动）选项，代表不指向异常处理函数，需要向技术人员返回发生冲突的数据记录，并暂停索引修改事务，等待技术人员对发生冲突的数据记录修改完毕后，再继续执行索引修改事务（或者技术人员指示回滚时，回滚索引修改事务）；如果该异常处理参数ON EXCEPTION命中User specific handler func（自动）选项，代表指向异常处理函数，则只需要根据对应操作类型下挂载的该异常处理函数（通常在DDL语句中会包含该异常处理函数的函数名或者指针），对该数据记录进行转换即可。

也即是说，对该数据表中存储的每一条数据记录，若该数据记录并非最新版本，且该数据列的列类型转换存在冲突的情况下，计算设备获取该DDL事务的异常处理参数ONEXCEPTION；在该异常处理参数ON EXCEPTION指向异常处理函数时，即该异常处理参数ONEXCEPTION命中User specific handler func（自动）选项，基于该操作类型下挂载的该异常处理函数，对该数据记录进行转换；在该异常处理参数ON EXCEPTION不指向异常处理函数，或该异常处理函数对该数据记录转换失败时，即该异常处理参数ON EXCEPTION命中Manual（手动）选项或者异常处理函数的返回值指示转换失败，暂停该索引修改事务，向触发该DDL事务的设备返回发生冲突的该数据记录。

在上述过程中，通过对DDL语句进行语法扩展，使得在DDL语句中支持指定DDL事务的异常处理机制，包括自动调用预定义的异常处理函数进行处理，或者进行人工处理，使得即使在转换列类型时发生异常，也不必整体回滚DDL事务和索引修改事务，而是能够暂停下来，等待异常解决之后再恢复启动，能够大大提升DDL事务和索引修改事务的执行成功率，提高数据库系统的资源利用率。

在一些实施例中，如果数据库系统提供多种默认值显示方式，根据上一实施例中介绍的对DDL语句的语法扩展，可知默认值显示方式SET DEFAULT VALUE SHOW MODE具有两种可选的取值：0和1，当SET DEFAULT VALUE SHOW MODE取值为0时，沿用主流的默认值显示方式，即所有未赋值且定义了默认值的数据列所对应的字段数据，都显示最新的默认值；当SET DEFAULT VALUE SHOW MODE取值为1时，则使用数据记录的当前版本对应的默认值版本来进行显示，即能够支持查询与数据记录当前版本对应的历史默认值，而非一律显示最新的默认值。

也即是说，在向新增的数据列对应的字段数据中填充默认值时，基于该DDL事务的默认值设置方式SET DEFAULT VALUE SHOW MODE，向该字段数据中填充符合对应版本的默认值，该对应版本包括该数据记录的最新版本或者插入版本。

示意性地，当SET DEFAULT VALUE SHOW MODE取值为0时，代表填充的是该对应版本为最新版本的默认值，换言之查询该数据记录时会显示最新版本的默认值；当SETDEFAULT VALUE SHOW MODE取值为1时，代表填充的是该对应版本为插入版本的默认值，换言之查询该数据记录时会显示与插入版本对应的旧版本的历史默认值。例如，在版本7的数据表中插入数据列m1，版本7的默认值为10，在版本9时将数据列m1的默认值从10修改为20，那么在对数据记录进行版本转换时，如果默认值显示方式SET DEFAULT VALUE SHOW MODE= 0，则向字段m1填充最新版本9下最新的默认值20，如果默认值显示方式SET DEFAULTVALUE SHOW MODE = 1，则向字段m1填充旧版本7对应的历史默认值10。

503、计算设备将该数据表和该索引均标记为发布状态。

在对上述步骤502执行完毕后，计算设备将索引从仅允许写入（write only）状态修改为发布（public）状态，同时将数据表从检查（checking）状态修改为发布（public）状态。

504、计算设备在该数据表的数据字典中，对该数据列和该索引的定义执行该索引修改事务所指示的修改。

在上述过程中，计算设备确定该索引修改事务所关联的数据表，访问该数据表的数据字典，在该数据字典中对该数据列和该索引的定义执行对应的修改之后，执行下述步骤505。

505、计算设备提交该索引修改事务，并将该DDL事务的跟踪信息置为已完成状态。

由于在索引修改事务的执行期间，同时还将DDL事务的跟踪信息置为未完成状态，而此时索引修改事务也已经执行和提交完毕了，因此还需要对应更新DDL事务的跟踪信息，即将未完成状态修改为已完成状态，代表对该DDL事务异步进行的索引修改事务也已经提交完毕了，该DDL事务以及其关联的索引修改事务都已经结束。

上述所有可选技术方案，能够采用任意结合形成本公开的可选实施例，在此不再一一赘述。

本申请实施例提供的方法，通过对DDL事务所关联的索引修改事务的执行流程进行介绍，能够确保在DDL事务涉及到修改列类型且列上建立有索引时，能够在修改数据表中数据记录的同时还在索引结构中修改关联的索引记录，保证数据表中数据记录与索引结构中的索引记录二者之间的数据一致性，并且还介绍了如果将数据记录从旧版本转换到最新版本（即记录解析算法），能够保证后续的查询事务不会出错。

在上述实施例涉及记录解析算法的基础上，在本申请实施例中将以数据表中的任一条数据记录的解析转换流程为例进行说明，图7是本申请实施例提供的一种数据记录解析转换的原理性流程图，如700所示，该解析转换流程由计算设备执行，该解析转换流程包括如下步骤：

步骤1、获取一条数据记录。

步骤2、提取数据记录的记录插入版本号和记录版本号。

其中，该记录插入版本号是指数据记录的起始版本号，该记录版本号是指数据记录的当前版本号。

步骤3、判断记录版本号是否等于当前表版本？如果记录版本号等于当前表版本，说明无需对数据记录进行转换，进入步骤22；如果记录版本号不等于当前表版本，说明需要对数据记录进行转换，进入步骤4。

其中，该当前表版本是指当前数据表的表定义的最新版本号。

步骤4、判断记录解析表是否已经存在？如果记录解析表已经存在，说明之前已经生成过两个版本之间相应的字符映射关系，直接复用即可，进入步骤7；如果记录解析表不存在，说明之前没有生成过两个版本之间相应的字符映射关系，需要生成字符映射关系，进入步骤5。

其中，该记录解析表是指根据DDL操作表中从当前版本到最新版本之间发生的至少一条DDL操作记录，对数据记录所生成的从当前版本到最新版本之间的字符映射关系（以如表3所示的表格形式来呈现）。

步骤5、提取之间加载的表对象集合，该表对象集合基于对应数据表的DDL操作表中与表对象绑定的各条DDL操作记录而构造得到。

也即是说，从整个DDL操作表中，筛选出与本数据表相关的表对象（如数据表中的数据列）绑定的各条DDL操作记录，并基于筛选得到的各条DDL操作记录构造一个表对象集合（例如表2示出了一种可能的表对象集合的实施方式）。

步骤6、构造从记录版本号到当前表版本的记录解析表。

例如，基于与表2类似的表对象集合，构造与表3类似的记录解析转换表（即字段映射关系）。

步骤7、基于记录解析表，判断是否新增列？如果新增列，进入步骤8；如果没有新增列，进入步骤9。

步骤8、获取对应字段的插入值。

需要说明的是，只有等于当前记录版本号的新增列（即新增列的DDL操作记录中记载的版本号等于该记录版本号），可能会产生DDL语句中已经设定了插入值，需要进入获取插入值的步骤，对于其他的新增列，可跳过步骤8直接进入到默认值部分的处理逻辑中。

步骤9、判断是否选择默认值？即判断是否默认值设置方式SET DEFAULT VALUESHOW MODE = 0？如果默认值设置方式SET DEFAULT VALUE SHOW MODE = 0，进入步骤10；如果默认值设置方式SET DEFAULT VALUE SHOW MODE ≠ 0，进入步骤11。

步骤10、根据算法选择对应的历史默认值。

可选地，以版本号随着时间的推移呈单调递增为例说明，根据上述步骤6中构造的记录解析表或者上述步骤4中复用的记录解析表，生成一个默认值分段，例如，版本6修改默认值为D1，版本10修改默认值为D2；接着，找到小于上述步骤2中获取的记录插入版本号的最大版本的默认值，例如，记录插入版本号为7，则找到小于记录插入版本号的最大版本6下的默认值D1（D1是历史默认值，因为最新默认值是D2）；需要说明的是，针对版本6之前没有设置默认值的情况，则需要选择大于记录插入版本号的最小版本的默认值，例如，记录插入版本号为5，但在版本5之后没有设置过默认值，版本6时首次设置默认值D1，则找到大于记录插入版本号的最小版本6下的默认值D1。

步骤11、直接使用当前表版本的表定义中的最新默认值。

上述步骤11中沿用的是主流的默认值显示方式，即使用修改后的最新的表定义中对应数据列的最新默认值，作为新增列中插入的字段数据的填充值。

步骤12、基于记录解析表，判断是否删除列？如果删除列，进入步骤13；如果没有删除列，进入步骤14。

也即是说，判断从记录版本号到当前表版本之间是否存在删除的数据列。

步骤13、跳过被删除的数据列对应的字段数据。

因此从记录版本号到当前表版本之间，曾经删除过对应的数据列，即这一数据列对应的字段数据在最新版本中是不存在的，因此只需要跳过该字段数据即可。

步骤14、基于记录解析表，判断是否列位置发生变化？如果列位置发生变化，进入步骤15；如果列位置没有发生变化，进入步骤16。

步骤15、针对当前提取的字段数据，按照字段映射关系从原始位置移动到目标位置。

换言之，按照字段映射关系，确定出当前版本下字段数据的原始位置，和最新版本下字段数据的目标位置，并在当前版本的数据记录中提取原始位置的字段数据，并将提取出的字段数据移动该目标位置。需要说明的是，如果某一字段数据发生了多次位置变化，只需要从原始位置移动到最后一次发生位置变化时最终的目标位置即可。

步骤16、基于记录解析表，判断是否变换列类型？如果变换列类型，进入步骤17；如果没有变换列类型，进入步骤22。

需要说明的是，如果某一字段数据（对应的数据列）发生了多次列类型变换，只需要从原始类型变换到最后一次发生列类型变换时最终的目标类型即可。

步骤17、判断是否指定了异常处理函数？如果指定了异常处理函数，进入步骤18；如果未指定异常处理函数，进入步骤19。

可选地，基于DDL事务的异常处理参数ON EXCEPTION来判断是否指定异常处理函数。如果该异常处理参数ON EXCEPTION命中User specific handler func（自动）选项，确定指定了异常处理函数，并查询挂载的该异常处理函数的函数名和指针；如果该异常处理参数ON EXCEPTION命中Manual（手动）选项，确定未指定异常处理函数，暂停该索引修改事务，向触发该DDL事务的设备返回发生冲突的该数据记录。

步骤18、调用对应的异常处理函数。

步骤19、对被修改列类型的字段数据实现从原始类型到目标类型的数据类型转换。

步骤20、判断是否数据类型转换成功？如果数据类型转换成功，代表数据类型转换成功，或者无需进行转换（比如转换前后类型兼容），进入步骤22；如果数据类型转换失败，是指经过异常处理函数仍然不能成功转换或者没有指定异常处理函数且转换失败的情况，进入步骤21。

步骤21、数据类型转换失败，暂停本事务，返回警告失败的数据记录的记录ID，例如，由技术人员根据返回的记录ID，使用携带跳转参数-skip的查询语句来手动处理该数据记录对应的字段数据，以进行相应的变更来解决相关异常，在异常解决之后，可通过DDL_JOB job_id CONTINUE EXECUTION语句来触发本事务在中断后继续执行（或者之前本事务如果已经回滚了，可以再次发起执行本事务）。

步骤22、数据记录的所有字段数据均转换成功，代表记录解析算法流程结束。

正是由于某个DDL语句中可能涉及到多种操作类型的DDL变更，即列变化可能是对某一数据列的组合变化，因此会逐一判断是否存在各种操作类型的转换，防止遗漏掉某一类对字段数据的映射操作。

在上述实施例中，介绍了在索引修改事务中如何将数据记录从当前版本转换到最新版本的记录解析算法，这一记录解析算法是由涉及到修改列类型且数据列上建立了索引的DDL事务所触发的，而在一些实施例中，在数据库系统的后台可进行性能优化，即，通过在后台维护一个周期处理进程或线程，通过该周期处理进程或线程异步处理将存储的数据记录转换到最新版本，这样是为了防止DDL操作表中记录的各个DDL操作记录迟迟没有进行数据落盘，从而整体导致用户业务（如查询事务）变慢，从而能够将DDL变更在后台定期异步消化掉。

图8是本申请实施例提供的一种周期性性能优化策略的原理性流程图，如800所示，该周期性性能优化策略由计算设备执行，该周期性性能优化策略包括如下步骤：

步骤1、启动后台处理进程或线程。

步骤2、获取最新版本下数据表的表定义。

步骤3、获取一个事务时间戳或事务快照（步骤3并非必须执行的步骤）。

步骤4、以数据存储的最小单元（例如数据块block）为单位，处理当前block中的数据记录，即利用记录解析算法将当前block中的每条数据记录转换到最新版本。

步骤5、处理下一个block，即利用记录解析算法将下一个block中的数据记录转换到最新版本。

步骤6、判断当前表版本（最新版本）是否与block中最小（即最旧）的记录版本号相等？如果当前表版本与block中最小的记录版本号相等，进入步骤7；如果当前表版本与block中最小的记录版本号不相等，进入步骤8。

步骤7、判断是否对当前数据表处理结束？如果对当前数据表处理结束，进入步骤19；如果对当前数据表处理未结束，返回步骤5。

步骤8、读取当前block中的下一条数据记录。

步骤9、判断是否对当前block中所有数据记录处理结束？如果对当前block中所有数据记录处理结束，进入步骤18；如果尚未对当前block中所有数据记录处理结束，进入步骤11。

步骤10、判断当前读取到的数据记录是否为最新版本？如果当前读取到的数据记录为最新版本，返回步骤8；如果当前读取到的数据记录不为最新版本，进入步骤11。

步骤11、利用之前实施例中涉及的记录解析算法，将当前读取到的数据记录转换为最新版本。

步骤12、判断是否对当前转换的数据记录转换成功？如果对当前转换的数据记录转换成功，进入步骤17；如果对当前转换的数据记录转换失败，进入步骤13。

步骤13、判断是否指定了异常处理函数？如果指定了异常处理函数，进入步骤14；如果未指定异常处理函数，进入步骤16。

可选地，基于DDL事务的异常处理参数ON EXCEPTION来判断是否指定异常处理函数。如果该异常处理参数ON EXCEPTION命中User specific handler func（自动）选项，确定指定了异常处理函数，进入步骤14；如果该异常处理参数ON EXCEPTION命中Manual（手动）选项，确定未指定异常处理函数，进入步骤16。

步骤14、调用指定的异常处理函数处理字段数据的类型转换异常。

步骤15、判断异常处理函数是否处理成功？如果异常处理函数处理成功，进入步骤17，如果异常处理函数处理失败，进入步骤16。

步骤16、记录处理失败的数据记录的记录ID。

可选地，对每张数据表将处理失败的数据记录的记录ID（row_id）统一存放到一个集合中，并将集合集中返回给技术人员，以供技术人员手动修复相关异常，在对异常修复完毕之后，可通过DDL_JOB job_id CONTINUE EXECUTION语句来触发本事务在中断后返回到步骤8继续执行（或者之前本事务如果已经回滚了，可以再次发起执行本事务）。

步骤17、将最新版本的数据记录写回数据表，返回步骤8。

换言之，按照最新表结构写回转换完毕的数据记录。

步骤18、标记当前block中最小（即最旧）的记录版本号，如果发生异常导致步骤16中记录了至少一个记录ID即集合不是空集，则不修改当前block最小的记录版本号，返回步骤5。

步骤19、扫描本数据表的全部block，获取整张数据表中最小（即最旧）的记录版本号。

步骤20、根据步骤19中获取到的最小的记录版本号，清理掉DDL操作表中已落盘的DDL操作记录，需要注意的是，保留针对默认值进行变更的DDL操作记录，以便于查询历史默认值。

例如，将所有小于步骤19中获取到的最小的记录版本号的DDL操作记录从DDL操作表中删除（也可以不删除，转存到历史表中，并通过反向操作可以恢复表数据到DDL变更之前的版本，以便于进行数据回溯）。

步骤21、提交数据字典对应表信息变更，完成优化。

需要说明的是，在集群数据库系统内，本计算设备在后台完成数据记录的变更优化后，不需要同步到集群内所有计算设备。这是由于在记录变更后，下次用户读取到数据记录时会发现数据记录已经是最新版本，那么不需要进行再次解析转换。计算设备中之前加载并生成的记录解析表，会随着下一次表结构的刷新而被清理掉，后续加载表结构的时候，会相应的减少加载DDL操作记录的条数（因此步骤20中已经清理掉了一部分过时的DDL操作记录），从而减少生成的记录解析表的数据量，以减少计算设备的内存使用量。

在本申请实施例中，在符合转换条件时，对数据库中的每张数据表，调用对应的DDL操作表，将该数据表中的每条数据记录均转换为最新版本，其中，对于后台处理进程或线程来说，该转换条件是指每隔目标时长，以周期性发起主动数据落盘，或者，该转换条件为负载程度低于负载阈值，以仅在计算设备较为空闲的时候发起主动数据落盘，其中负载阈值为任一大于0的数值，本申请实施例不对转换条件的内容进行具体限定。

通过每隔一段时间能够将表中所有数据记录转换到最新版本，从而减少用户在读取数据记录时所需要进行的转换工作（即及时对DDL操作落盘后，用户能够直接读取最新版本的数据记录，而无需即用即转），因此，保证了不会由于需要在用户业务处理数据记录时进行数据转换而降低用户业务的处理效率，同时后台完成优化后也可以清理掉不必要的DDL操作表中DDL操作记录，减少不同版本间发生记录解析和转换时所需构造的记录解析表中的内容，降低内存占用率，提升数据转换效率。

进一步地，后台的周期处理进程或线程可灵活开启或关闭，例如根据数据库系统的忙闲程度或负载程度，随机进行启动或随机进行暂停，并且由于只需要根据记录版本号就能够确定是否需要转换，因此后台处理任务的粒度和执行方式都非常灵活，能够做到按需执行。

在上述各个实施例中，分别介绍了在线DDL执行流程、记录解析算法和后台周期处理进程或线程异步进行数据落盘的执行流程，而在本申请实施例中，将以一个原理性流程图的方式，总体介绍通用在线DDL框架下的在线DDL执行流程。

图9是本申请实施例提供的一种在线DDL事务的原理性流程图，如900所示，该在线DDL事务由计算设备执行，该通用在线DDL框架下的在线DDL执行流程包括如下步骤：

步骤1、开始执行一个在线DDL事务。

可选地，在该在线DDL事务开始执行的同时，新增一个对应的DDL事务的跟踪信息，该跟踪信息用于记录DDL事务的执行情况，便于对DDL事务在异常中断后进行恢复执行。

步骤2、按照数据库原生的DDL逻辑，准备DDL事务执行所需数据。

步骤3、基于步骤2中准备的关于DDL事务的列变更信息，提取DDL事务修改表列的操作类型。

步骤4、判断是否加列（增加列）？如果加列，进入步骤7；如果没有加列，进入步骤5。

步骤5、判断是否删除列？如果删除列，进入步骤8；如果没有删除列，进入步骤6。

步骤6、判断是否修改列？如果修改列，进入步骤10；如果没有修改列，进入步骤28。

步骤7、对每一个增加的数据列会填充一个add_column结构（即操作解析信息），放到一个操作解析信息集合里面。

步骤8、对每一个删除的数据列会填充一个drop_column结构（即操作解析信息），放到一个操作解析信息集合里面。

步骤9、处理步骤7、8、10中生成的操作解析信息集合，为操作解析信息集合中每一个结构（即操作解析信息），在DDL操作表DDL_OPERATOR中创建一行对应的DDL操作记录。换言之，按照操作解析信息集合中存储的每个结构（即操作解析信息），更新DDL操作表。

步骤10、对每一个修改的数据列会填充一个change column结构（即操作解析信息），放到步骤7和8产生的操作解析信息集合中。

步骤11、判断修改的数据列是否被索引包含且涉及修改列类型？如果数据列被索引包含且涉及修改列类型，进入步骤12；如果数据列没有被索引包含或不涉及修改列类型，进入步骤9。

步骤12、修改对应索引为仅允许写入（write only）状态。

其中，索引在仅允许写入（write only）状态下，只能够被修改，而不允许被优化器选中做查询事务。此时可划分为两种情况：列类型兼容转换，涉及缩小字段长度且数据列在索引定义中指定；或者，列类型不兼容转换，且数据列在索引定义中指定。

步骤13、修改数据表为检查（checking）状态。

步骤14、在DDL事务的跟踪信息中标记DDL事务为未完成状态。

步骤15、处理步骤7、8、10中生成的操作解析信息集合，为操作解析信息集合中每一个结构（即操作解析信息），在DDL操作表DDL_OPERATOR中创建一行对应的DDL操作记录。换言之，按照操作解析信息集合中存储的每个结构（即操作解析信息），更新DDL操作表。

步骤16、提交DDL事务，即将对数据表的DDL事务修改的部分内容更新到该数据表的数据字典中。

步骤17、启动索引数据类型变更任务，即启动索引修改事务。

步骤18、开始读取数据表中的下一条数据记录。

步骤19、判断索引数据是否处理完毕？如果索引记录处理完毕，进入步骤26；如果索引记录未处理完毕，进入步骤20。

步骤20、根据之前实施例中涉及的记录解析算法，将旧版本的数据记录转换为最新版本，同时也会相应修改该数据记录对应的索引记录。

步骤21、判断是否数据记录的记录版本号并非最新版本且类型转换存在冲突？这里主要判断当前转换的索引所对应数据列的列类型转换是否有异常。如果记录版本号并非最新版本且类型转换存在冲突，进入步骤22；如果记录版本号为最新版本或类型转换不存在冲突，代表当前的数据记录转换完毕，进入步骤18以处理下一条数据记录。

在当前的数据记录转换完毕的情况下，如果索引记录本身的版本就是最新版本，说明不需要对数据记录进行转换，说明用户业务已经事先更新了数据记录并同步了索引记录，转到步骤18；如果索引记录本身的版本并非最新版本，那么需要将数据记录转换到最新版本并同步更新索引记录，如果转换成功（即类型转换不存在冲突），转到步骤18。

步骤22、判断是否指定了异常处理函数？如果指定了异常处理函数，进入步骤24；如果未指定异常处理函数，进入步骤23。

可选地，基于change column结构中handler字段中记载的异常处理参数ONEXCEPTION来判断是否指定了异常处理函数。如果该异常处理参数ON EXCEPTION命中Userspecific handler func（自动）选项，确定指定了异常处理函数，进入步骤24；如果该异常处理参数ON EXCEPTION命中Manual（手动）选项，确定未指定异常处理函数，进入步骤23。

步骤23、等待技术人员手动处理完毕异常后，接收DDL继续命令。

在上述过程中，需要中断索引转换过程即暂停索引修改事务，并向触发DDL事务的设备输出发送冲突的数据记录的记录ID（例如仅输出主键ID），等待技术人员手动对异常进行处理之后，使用扩展语法的SHOW ACTIVE DDL_JOB语句查询到正在活跃的DDL事务的事务ID，再使用扩展语法的DDL_JOB job_id CONTINUE EXECUTION语句来作为DDL继续命令，触发返回步骤18，并从上次停止的block开始继续执行索引修改事务。

步骤24、使用挂载的异常处理函数解决异常。

步骤25、判断是否处理异常成功？如果处理异常成功，返回步骤18；如果处理异常失败，进入步骤23。

步骤26、索引数据处理完毕，修改数据表和索引为公布（public）状态。

步骤27、更新数据表的数据字典，进入步骤29。

步骤28、按照原生DDL逻辑修改数据表中对应的表定义，提交DDL事务。

步骤29、将DDL事务的跟踪信息修改为已完成状态。

在本申请实施例中，提供了一种执行在线DDL事务的通用框架，使得能够在用户生产环境运行时在线变更表定义（而无需停机进行离线DDL变更），因此不会阻塞用户业务的执行，且DDL事务的执行性能优异，能够以最快的方式完成DDL事务对应的表结构变更。此外，在该通用框架下不需要额外占用与原表相同大小的空间来存储临时数据（即临时表），这对于在用户数据大表上进行DDL变更具有关键性的意义。

进一步的，将整体需要长时间才能完成的扫描全表数据的数据版本转换过程，分解到了DDL事务提交之后，用户业务具体访问到数据记录的时候才进行记录解析和版本变换（这一过程能够跨越多个版本，直接转换到最新版本），从而提升了DDL事务的执行速度，提高了数据库连续服务的能力。

进一步的，扩展了DDL语句的语法，使得对外支持手动修复异常或者定义某一数据转换规则（即挂载预定义的异常处理函数），以提升DDL事务的执行成功率，也使得数据库集群内的计算资源能够得到最大程度的节约。

进一步的，这一通用框架下离线DDL转变为在线DDL的执行模式是细粒度的（例如以单个block为最小处理单元），降低了DDL事务从离线模式转换为在线模式的复杂度，从而能够细粒度地支持DDL语句的各种语法。

进一步的，通过对每一条数据记录保留记录插入版本号，从而根据不同DDL操作记录的产生时间，可设置多种默认值显示方式，从而在对应字段数据上插入历史默认值或者最新默认值，更能体验出数据记录插入到数据库系统时的真实情况。

进一步的，提供后台的版本推进能力，消除由于对数据记录临时转换而对用户业务造成的性能损失，使得最终用户能够对之前需要长时间完成的DDL操作达到无感知的体验。

进一步的，该通用框架其主要逻辑均在应用层实现，能够方便的适配各种存储引擎，在存储引擎层只需要增加对记录版本号（可选地还包括记录插入版本号）的存储即可，具有很强的通用性。

在上述各个实施例中，分别介绍了通用在线DDL框架下的在线DDL事务执行流程、记录解析算法、后台性能优化进程或线程的相关处理逻辑，而在本申请实施例中，将对通用在线DDL框架下DML事务的处理流程进行详细说明。

经过上述各个实施例的介绍可知，如果相关的DDL操作尚未落盘，那么针对数据记录的记录解析和版本变换可异步到DML事务具体访问到对应的数据记录时来执行。图10是本申请实施例提供的一种DML事务的执行流程图，如图10所示，该实施例由数据库系统中的任一计算设备执行，该实施例包括下述步骤：

1001、计算设备响应于数据操纵语言DML事务，获取该DML事务所操作的数据表的数据定义语言DDL操作表。

在一些实施例中，用户在终端上登录应用客户端，触发应用客户端生成DML请求，例如，DML请求为查询数据表A中某条数据记录中某一字段数据的取值，或者，查询数据表A中主键ID位于指定的查询范围内的所有数据记录，本申请实施例不对DML请求的类型进行具体限定。应用客户端在生成DML请求之后，可调用API将该DML请求发送至计算设备，比如，该API可以是MySQL API。

在一些实施例中，计算设备接收应用客户端的任一用户请求，解析该用户请求的头字段，当该头字段指示该用户请求为DML请求时，解析该DML请求的数据字段，得到该DML请求中携带的DML语句，基于该DML语句可构建一个唯一对应的DML事务。可选地，计算设备为该DML语句创建一个新的DML进程或线程，或者复用已创建的某一DML进程或线程，并通过该DML进程或线程执行该DML语句对应的DML事务。

在一些实施例中，计算设备对该DML语句进行解析，以确定该DML语句所涉及操作的数据表，进而可从内存中访问针对该数据表的DDL操作表。可选地，为每个数据表单独维护一张各自的DDL操作表，或者，所有的数据表的DDL操作表集成在一张大表上，此时需要从大表中分解出与该数据表对应的子表作为该数据表的DDL操作表。

1002、计算设备基于该DDL操作表，对该DML事务在该数据表中所涉及的数据记录进行对应的操作。

在一些实施例中，在该DML事务涉及读取该数据表中已存储的数据记录的情况下，若该已存储的数据记录是最新版本，向触发该DML事务的设备返回该已存储的数据记录；若该已存储的数据记录并非最新版本，基于该DDL操作表，将该数据记录转换为最新版本，向触发该DML事务的设备返回转换得到的（最新版本的）数据记录。

在上述过程中，由于数据表中存储的数据记录并不一定是处于最新版本的，但为避免DML事务出错，需要保证DML事务读到的最新版本的数据记录，因此需要判断读到的数据记录是否是最新版本，如果已经是最新版本（说明索引修改事务或者后台优化进程或线程已经对DDL操作完成了数据落盘），那么无需进行转换，直接返回读到的最新版本的数据记录；如果并非是最新版本（说明DDL操作尚未完成数据落盘），那么需要利用记录解析算法，将数据记录转换到最新版本，然后返回转换得到的（最新版本的）数据记录。

在一些实施例中，计算设备通过如下操作，来判断读到的数据记录是否是最新版本：获取该已存储的数据记录的记录版本号和该数据表的表结构定义的最新版本号；在该记录版本号等于该最新版本号的情况下，确定该已存储的数据记录是最新版本；在该记录版本号小于该最新版本号的情况下，确定该已存储的数据记录并非最新版本。

在上述过程中，由于已经对数据记录的存储格式进行了改进，即在数据记录的存储格式中还会存储记录版本号，因此在读取数据记录的同时能够获取到记录版本号，同时以版本号随着时间的推移呈单调递增为例，在DDL操作表中还会记录有表结构定义的最新版本号（即针对表定义发起的DDL操作记录中的最大版本号），如果该记录版本号等于该最新版本号，说明读到的数据记录本身就是最新版本，说明无需进行版本转换，如果该记录版本号小于该最新版本号，说明读到的数据记录并非是最新版本，说明需要进行版本转换。

在一些实施例中，如果DML事务是只读事务，那么只需要返回最新版本的数据记录即可，但如果DML事务是读写事务，那么在将数据记录转换为最新版本之后，还需要将最新版本的数据记录写回数据表中，换言之，在该DML事务涉及向该数据表中写入数据记录的情况下，基于该数据表的具有最新版本号的表结构定义，向该数据表中写入符合该表结构定义的数据记录。

在上述过程中，能够保证只读事务读取到最新版本的数据记录，且能够保证读写事务写入的是符合最新的表结构定义的数据记录，从而全方面的保证了数据库中的数据一致性。

在一些实施例中，在该DML事务涉及从该数据表中删除数据记录的情况下，那么需要将该DML事务指定删除的数据记录标记为删除状态，即，不需要对数据记录真实进行删除，而是标记成删除状态即可（后续对本数据表进行处理时会跳过这一条数据记录）。

1003、计算设备提交该DML事务。

其中，DML事务的提交流程与DDL事务的提交流程类似，但DML事务无需维护跟踪信息，这里不再赘述。

上述所有可选技术方案，能够采用任意结合形成本公开的可选实施例，在此不再一一赘述。

本申请实施例提供的方法，通过在DML事务访问到某条数据记录时，才对该数据记录异步落实DDL操作表中各条DDL操作记录所指示的操作，以保证在通用在线DDL框架下，即使DDL事务进行了在线变更，但相关的DML事务不会访问到错误版本的数据记录，并且由于单个DML事务涉及访问的数据记录通常数量较少，因此即使需要对数据记录进行记录解析和版本转换，也不会对DML事务造成长时间阻塞，也即对DML事务的影响可忽略不计，从而能够提升数据库系统的事务执行性能。

在上述实施例中，介绍了计算设备对DML事务的执行流程，而在本申请实施例中，将以一个原理性流程图对整个DML事务的执行流程进行详细说明，并且针对DML事务也可对外提供手动处理异常或者挂载异常处理函数以处理异常这两种不同的异常处理机制，下面将详细进行说明。

图11是本申请实施例提供的一种DML事务执行过程的原理性流程图，如1100所示，该DML事务执行过程由数据库系统中的任一计算设备执行，该DML事务执行过程包括如下步骤：

步骤1、开始一个DML事务，获取最新版本下对应数据表的表定义。

步骤2、根据表定义，加载数据表相关的DDL操作表，并构建相对应的表对象集合。其中，该表对象集合基于该DDL操作表中与表对象绑定的各条DDL操作记录而构造得到。

也即是说，从整个DDL操作表中，筛选出与本数据表相关的表对象（如数据表中的数据列）绑定的各条DDL操作记录，并基于筛选得到的各条DDL操作记录构造一个表对象集合（例如表2示出了一种可能的表对象集合的实施方式）。

步骤3、处理下一条数据记录。

在上述步骤3中，可能是从数据表中读取一条数据记录，也可能是插入（insert）一条数据记录，如果是插入数据记录的话就不需要再读取数据了。

步骤4、判断是否还存在需要处理的数据记录？如果存在需要处理的数据记录，进入步骤6；如果不存在需要处理的数据记录，进入步骤5。

步骤5、提交DML事务，进入步骤17。

步骤6、判断DML事务是否为只读事务？如果DML事务是只读事务，进入步骤9；如果DML事务不是只读事务，进入步骤7。

步骤7、使用最新版本下表定义的表结构来组成待写入的数据记录。（如果涉及到删除数据记录的话，不需要重新组合数据记录，只需要将数据记录标记为删除状态即可）。

步骤8、保存数据记录（如果涉及到删除数据记录的话，只需要将数据记录标记为删除状态并保存即可），返回步骤3。

步骤9、获得数据记录，并提取该数据记录的记录版本号与记录插入版本号。

步骤10、应用（apply）记录版本号到当前表版本之间的所有DDL操作，即将数据记录从当前版本转到最新版本。

可选地，利用记录版本号到最新版本之间对应发生的各条DDL操作记录来解析本条数据记录，提取发生变更的相应字段数据，映射到最新版本的数据记录的对应字段数据中，与之前实施例中的记录解析算法相同，这里不做赘述。

步骤11、判断是否数据记录的转换有异常发生？如果数据记录的转换没有异常发生，代表对本条数据记录完成数据转换操作，进入步骤16；如果数据记录的转换有异常发生，需要开启异常处理逻辑，进入步骤12。

步骤12、判断是否指定了异常处理函数？如果指定了异常处理函数，进入步骤13；如果未指定异常处理函数，进入步骤14。

可选地，基于DML语句中记载的异常处理参数ON EXCEPTION来判断是否指定了异常处理函数。如果该异常处理参数ON EXCEPTION命中User specific handler func（自动）选项，确定指定了异常处理函数，进入步骤13；如果该异常处理参数ON EXCEPTION命中Manual（手动）选项，确定未指定异常处理函数，进入步骤14。

步骤13、使用指定（挂载）的异常处理函数对本条数据记录进行处理，进入步骤15。

步骤14、回滚DML事务，并告警发生异常的数据记录的主键ID，进入步骤17。

可选地，在等待用户手动对发生异常的数据记录修改完毕并消除了异常之后，可输入DML重试命令，重新开启一次DML事务。

步骤15、判断是否处理异常成功？如果处理异常成功，返回步骤16；如果处理异常失败，进入步骤14。

步骤16、判断是否需要向数据表中写回数据记录？如果需要向数据表中写回数据记录，进入步骤7，这时候数据记录已经解析完毕，只需要完成DML语句中指定的修改字段数据的部分修改操作；如果不需要向数据表中写回数据记录，返回步骤3。

上述步骤16中的判断，主要是判断获取本条数据记录是否是为了修改数据记录为目的所发起的DML操作。

步骤17、DML事务结束。

在本申请实施例中，通过在DML事务访问到某条数据记录时，才对该数据记录异步落实DDL操作表中各条DDL操作记录所指示的操作，以保证在通用在线DDL框架下，即使DDL事务进行了在线变更，但相关的DML事务不会访问到错误版本的数据记录，并且由于单个DML事务涉及访问的数据记录通常数量较少，因此即使需要对数据记录进行记录解析和版本转换，也不会对DML事务造成长时间阻塞，也即对DML事务的影响可忽略不计，从而能够提升数据库系统的事务执行性能。

图12是本申请实施例提供的一种事务执行装置的结构示意图，如图12所示，该装置包括：

确定模块1201，用于响应于数据定义语言DDL事务，在该DDL事务所操作的数据对象与数据表中的数据列相关联的情况下，确定该操作的操作类型；

创建模块1202，用于基于该操作类型，在该数据表的DDL操作表中为该操作创建对应的DDL操作记录，该DDL操作表用于建立该数据表中数据记录的不同版本之间的映射关系；

提交模块1203，用于在该数据表的数据字典中对该数据对象的定义执行该操作后，提交该DDL事务。

本申请实施例提供的装置，通过对DDL事务在DDL操作表中创建对应的DDL操作记录，使得DDL事务在完成对数据字典中存储的数据对象的定义的操作之后，无需等待在数据表中数据记录执行相关操作，即可提交DDL事务，这一在线DDL方式无需对数据表进行加锁，不会阻塞用户业务，并且能够适用于各种不同操作类型的DDL事务，从而提供了一种针对各类不同操作类型的DDL事务的通用在线DDL执行方式，能够提升数据库系统的事务执行性能。

在一种可能实施方式中，基于图12的装置组成，该创建模块1202包括：

生成单元，用于在解析该DDL事务所涉及的每一项操作的操作类型时，对该操作所涉及的每一个数据对象生成对应的操作解析信息；

存储单元，用于将该DDL事务的各项操作所涉及的各个数据对象的该操作解析信息，存储到操作解析信息集合中；

创建单元，用于在该DDL操作表中，为该操作解析信息集合中的每一个操作解析信息创建一条对应的该DDL操作记录。

在一种可能实施方式中，对该操作解析信息集合中的每一个操作解析信息，在该操作解析信息所对应的数据对象为数据列的情况下，该创建单元用于：

对每一个数据列的操作解析信息，在该操作解析信息对应的操作类型为增加列的情况下，生成增加该数据列的DDL操作记录；或，在该操作解析信息对应的操作类型为删除列的情况下，生成删除该数据列的DDL操作记录。

在一种可能实施方式中，对该操作解析信息集合中的每一个操作解析信息，在该操作解析信息所对应的数据对象为数据列的情况下，该创建单元用于：

对每一个数据列的操作解析信息，在该操作解析信息对应的操作类型为修改列的情况下，若该数据列不具有关联的索引或者该操作类型不涉及修改该数据列的列类型，生成修改该数据列的DDL操作记录。

在一种可能实施方式中，对该操作解析信息集合中的每一个操作解析信息，在该操作解析信息所对应的数据对象为数据列的情况下，该创建单元用于：

对每一个数据列的操作解析信息，在该操作解析信息对应的操作类型为修改列的情况下，若该数据列具有关联的索引并且该操作类型涉及修改该数据列的列类型，将该索引标记为仅允许写入状态，将该数据列所在的数据表标记为检查状态，将该DDL事务的跟踪信息置为未完成状态；生成修改该数据列的DDL操作记录。

在一种可能实施方式中，基于图12的装置组成，该装置还包括：

启动模块，用于对该数据列所关联的该索引，启动索引修改事务；

修改模块，用于响应于该索引修改事务，修改该数据列所在的数据表中的每一条数据记录和每一条数据记录所关联的索引记录；

标记模块，用于将该数据表和该索引均标记为发布状态；

该提交模块1203，还用于在该数据表的数据字典中，对该数据列和该索引的定义执行该索引修改事务所指示的修改；

该标记模块，还用于将该DDL事务的跟踪信息置为已完成状态。

在一种可能实施方式中，基于图12的装置组成，该修改模块包括：

转换单元，用于对该数据表中存储的每一条数据记录，若该数据记录并非最新版本，将该数据记录转换为最新版本；

写入单元，用于将该最新版本的数据记录写回该数据表；

该写入单元，还用于在该数据记录所关联的索引记录中，写入该最新版本的数据记录中与该索引对应的字段数据，以覆盖已有的同一字段数据。

在一种可能实施方式中，基于图12的装置组成，该转换单元包括：

查询子单元，用于查询该数据表的DDL操作表，得到该数据记录从当前版本到该最新版本之间发生的至少一条DDL操作记录；

生成子单元，用于基于该至少一条DDL操作记录，生成从该当前版本到该最新版本的字段映射关系；

映射子单元，用于基于该字段映射关系，对该数据记录的各个字段数据进行映射操作，得到该最新版本的数据记录。

在一种可能实施方式中，该映射子单元用于：

若该DDL操作记录对应的操作类型包括新增列，向新增的数据列对应的字段数据中填充插入值或默认值；

若该DDL操作记录对应的操作类型包括删除列，跳过被删除的数据列对应的字段数据；

若该DDL操作记录对应的操作类型包括修改列位置，将被修改位置的数据列对应的字段数据从原始位置移动至目标位置；

若该DDL操作记录对应的操作类型包括修改列类型，对被修改列类型的数据列对应的字段数据的数据类型从原始类型转换为目标类型。

在一种可能实施方式中，该映射子单元还用于：

基于该DDL事务的默认值设置方式，向该字段数据中填充符合对应版本的默认值，该对应版本包括该数据记录的最新版本或者插入版本。

在一种可能实施方式中，对该数据表中存储的每一条数据记录，若该数据记录并非最新版本，且该数据列的列类型转换存在冲突的情况下，基于图12的装置组成，该装置还包括：

获取模块，用于获取该DDL事务的异常处理参数；

第一转换模块，用于在该异常处理参数指向异常处理函数时，基于该操作类型下挂载的该异常处理函数，对该数据记录进行转换；

返回模块，用于在该异常处理参数不指向异常处理函数，或该异常处理函数对该数据记录转换失败时，暂停该索引修改事务，向触发该DDL事务的设备返回发生冲突的该数据记录。

在一种可能实施方式中，基于图12的装置组成，该装置还包括：

第二转换模块，用于在符合转换条件时，对数据库中的每张数据表，调用对应的DDL操作表，将该数据表中的每条数据记录均转换为最新版本。

上述所有可选技术方案，能够采用任意结合形成本公开的可选实施例，在此不再一一赘述。

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

图13是本申请实施例提供的一种事务执行装置的结构示意图，请参考图13，该装置包括：

第一获取模块1301，用于响应于数据操纵语言DML事务，获取该DML事务所操作的数据表的数据定义语言DDL操作表；

操作模块1302，用于基于该DDL操作表，对该DML事务在该数据表中所涉及的数据记录进行对应的操作；

提交模块1303，用于提交该DML事务。

本申请实施例提供的装置，通过在DML事务访问到某条数据记录时，才对该数据记录异步落实DDL操作表中各条DDL操作记录所指示的操作，以保证在通用在线DDL框架下，即使DDL事务进行了在线变更，但相关的DML事务不会访问到错误版本的数据记录，并且由于单个DML事务涉及访问的数据记录通常数量较少，因此即使需要对数据记录进行记录解析和版本转换，也不会对DML事务造成长时间阻塞，也即对DML事务的影响可忽略不计，从而能够提升数据库系统的事务执行性能。

在一种可能实施方式中，该操作模块1302用于：

在该DML事务涉及读取该数据表中已存储的数据记录的情况下，若该已存储的数据记录是最新版本，返回该已存储的数据记录；若该已存储的数据记录并非最新版本，基于该DDL操作表，将该数据记录转换为最新版本，返回转换得到的数据记录。

在一种可能实施方式中，基于图13的装置组成，该装置还包括：

第二获取模块，用于获取该已存储的数据记录的记录版本号和该数据表的表结构定义的最新版本号；

确定模块，用于在该记录版本号等于该最新版本号的情况下，确定该已存储的数据记录是最新版本；

该确定模块，还用于在该记录版本号小于该最新版本号的情况下，确定该已存储的数据记录并非最新版本。

在一种可能实施方式中，该操作模块1302用于：

在该DML事务涉及向该数据表中写入数据记录的情况下，基于该数据表的具有最新版本号的表结构定义，向该数据表中写入符合该表结构定义的数据记录。

在一种可能实施方式中，该操作模块1302用于：

在该DML事务涉及从该数据表中删除数据记录的情况下，将该DML事务指定删除的数据记录标记为删除状态。

上述所有可选技术方案，能够采用任意结合形成本公开的可选实施例，在此不再一一赘述。

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

图14是本申请实施例提供的一种计算设备的结构示意图，如图14所示，以计算设备为终端1400为例进行说明。可选地，该终端1400的设备类型包括：智能手机、平板电脑、MP3播放器（Moving Picture Experts Group Audio Layer III，动态影像专家压缩标准音频层面3）、MP4（Moving Picture Experts Group Audio Layer IV，动态影像专家压缩标准音频层面4）播放器、笔记本电脑或台式电脑。终端1400还可能被称为用户设备、便携式终端、膝上型终端、台式终端等其他名称。

通常，终端1400包括有：处理器1401和存储器1402。

可选地，处理器1401包括一个或多个处理核心，比如4核心处理器、8核心处理器等。可选地，处理器1401采用DSP（Digital Signal Processing，数字信号处理）、FPGA（Field－Programmable Gate Array，现场可编程门阵列）、PLA（Programmable LogicArray，可编程逻辑阵列）中的至少一种硬件形式来实现。在一些实施例中，处理器1401包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU（Central Processing Unit，中央处理器）；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器1401集成有GPU（Graphics Processing Unit，图像处理器），GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器1401还包括AI（Artificial Intelligence，人工智能）处理器，该AI处理器用于处理有关机器学习的计算操作。

在一些实施例中，存储器1402包括一个或多个计算机可读存储介质，可选地，该计算机可读存储介质是非暂态的。可选地，存储器1402还包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中，存储器1402中的非暂态的计算机可读存储介质用于存储至少一个程序代码，该至少一个程序代码用于被处理器1401所执行以实现本申请中各个实施例提供的事务执行方法。

在一些实施例中，终端1400还可选包括有：外围设备接口1403和至少一个外围设备。处理器1401、存储器1402和外围设备接口1403之间能够通过总线或信号线相连。各个外围设备能够通过总线、信号线或电路板与外围设备接口1403相连。具体地，外围设备包括：射频电路1404、显示屏1405、摄像头组件1406、音频电路1407、定位组件1408和电源1409中的至少一种。

外围设备接口1403可被用于将I/O（Input /Output，输入/输出）相关的至少一个外围设备连接到处理器1401和存储器1402。在一些实施例中，处理器1401、存储器1402和外围设备接口1403被集成在同一芯片或电路板上；在一些其他实施例中，处理器1401、存储器1402和外围设备接口1403中的任意一个或两个在单独的芯片或电路板上实现，本实施例对此不加以限定。

射频电路1404用于接收和发射RF（Radio Frequency，射频）信号，也称电磁信号。射频电路1404通过电磁信号与通信网络以及其他通信设备进行通信。射频电路1404将电信号转换为电磁信号进行发送，或者，将接收到的电磁信号转换为电信号。可选地，射频电路1404包括：天线系统、RF收发器、一个或多个放大器、调谐器、振荡器、数字信号处理器、编解码芯片组、用户身份模块卡等等。可选地，射频电路1404通过至少一种无线通信协议来与其它终端进行通信。该无线通信协议包括但不限于：城域网、各代移动通信网络（2G、3G、4G及5G）、无线局域网和/或WiFi（Wireless Fidelity，无线保真）网络。在一些实施例中，射频电路1404还包括NFC（Near Field Communication，近距离无线通信）有关的电路，本申请对此不加以限定。

显示屏1405用于显示UI（User Interface，用户界面）。可选地，该UI包括图形、文本、图标、视频及其它们的任意组合。当显示屏1405是触摸显示屏时，显示屏1405还具有采集在显示屏1405的表面或表面上方的触摸信号的能力。该触摸信号能够作为控制信号输入至处理器1401进行处理。可选地，显示屏1405还用于提供虚拟按钮和/或虚拟键盘，也称软按钮和/或软键盘。在一些实施例中，显示屏1405为一个，设置终端1400的前面板；在另一些实施例中，显示屏1405为至少两个，分别设置在终端1400的不同表面或呈折叠设计；在再一些实施例中，显示屏1405是柔性显示屏，设置在终端1400的弯曲表面上或折叠面上。甚至，可选地，显示屏1405设置成非矩形的不规则图形，也即异形屏。可选地，显示屏1405采用LCD（Liquid Crystal Display，液晶显示屏）、OLED（Organic Light-Emitting Diode，有机发光二极管）等材质制备。

摄像头组件1406用于采集图像或视频。可选地，摄像头组件1406包括前置摄像头和后置摄像头。通常，前置摄像头设置在终端的前面板，后置摄像头设置在终端的背面。在一些实施例中，后置摄像头为至少两个，分别为主摄像头、景深摄像头、广角摄像头、长焦摄像头中的任意一种，以实现主摄像头和景深摄像头融合实现背景虚化功能、主摄像头和广角摄像头融合实现全景拍摄以及VR（Virtual Reality，虚拟现实）拍摄功能或者其它融合拍摄功能。在一些实施例中，摄像头组件1406还包括闪光灯。可选地，闪光灯是单色温闪光灯，或者是双色温闪光灯。双色温闪光灯是指暖光闪光灯和冷光闪光灯的组合，用于不同色温下的光线补偿。

在一些实施例中，音频电路1407包括麦克风和扬声器。麦克风用于采集用户及环境的声波，并将声波转换为电信号输入至处理器1401进行处理，或者输入至射频电路1404以实现语音通信。出于立体声采集或降噪的目的，麦克风为多个，分别设置在终端1400的不同部位。可选地，麦克风是阵列麦克风或全向采集型麦克风。扬声器则用于将来自处理器1401或射频电路1404的电信号转换为声波。可选地，扬声器是传统的薄膜扬声器，或者是压电陶瓷扬声器。当扬声器是压电陶瓷扬声器时，不仅能够将电信号转换为人类可听见的声波，也能够将电信号转换为人类听不见的声波以进行测距等用途。在一些实施例中，音频电路1407还包括耳机插孔。

定位组件1408用于定位终端1400的当前地理位置，以实现导航或LBS（LocationBased Service，基于位置的服务）。可选地，定位组件1408是基于美国的GPS（GlobalPositioning System，全球定位系统）、中国的北斗系统、俄罗斯的格雷纳斯系统或欧盟的伽利略系统的定位组件。

电源1409用于为终端1400中的各个组件进行供电。可选地，电源1409是交流电、直流电、一次性电池或可充电电池。当电源1409包括可充电电池时，该可充电电池支持有线充电或无线充电。该可充电电池还用于支持快充技术。

在一些实施例中，终端1400还包括有一个或多个传感器1410。该一个或多个传感器1410包括但不限于：加速度传感器1411、陀螺仪传感器1412、压力传感器1413、指纹传感器1414、光学传感器1415以及接近传感器1416。

在一些实施例中，加速度传感器1411检测以终端1400建立的坐标系的三个坐标轴上的加速度大小。比如，加速度传感器1411用于检测重力加速度在三个坐标轴上的分量。可选地，处理器1401根据加速度传感器1411采集的重力加速度信号，控制显示屏1405以横向视图或纵向视图进行用户界面的显示。加速度传感器1411还用于游戏或者用户的运动数据的采集。

在一些实施例中，陀螺仪传感器1412检测终端1400的机体方向及转动角度，陀螺仪传感器1412与加速度传感器1411协同采集用户对终端1400的3D动作。处理器1401根据陀螺仪传感器1412采集的数据，实现如下功能：动作感应（比如根据用户的倾斜操作来改变UI）、拍摄时的图像稳定、游戏控制以及惯性导航。

可选地，压力传感器1413设置在终端1400的侧边框和/或显示屏1405的下层。当压力传感器1413设置在终端1400的侧边框时，能够检测用户对终端1400的握持信号，由处理器1401根据压力传感器1413采集的握持信号进行左右手识别或快捷操作。当压力传感器1413设置在显示屏1405的下层时，由处理器1401根据用户对显示屏1405的压力操作，实现对UI界面上的可操作性控件进行控制。可操作性控件包括按钮控件、滚动条控件、图标控件、菜单控件中的至少一种。

指纹传感器1414用于采集用户的指纹，由处理器1401根据指纹传感器1414采集到的指纹识别用户的身份，或者，由指纹传感器1414根据采集到的指纹识别用户的身份。在识别出用户的身份为可信身份时，由处理器1401授权该用户执行相关的敏感操作，该敏感操作包括解锁屏幕、查看加密信息、下载软件、支付及更改设置等。可选地，指纹传感器1414被设置终端1400的正面、背面或侧面。当终端1400上设置有物理按键或厂商Logo时，指纹传感器1414能够与物理按键或厂商Logo集成在一起。

光学传感器1415用于采集环境光强度。在一个实施例中，处理器1401根据光学传感器1415采集的环境光强度，控制显示屏1405的显示亮度。具体地，当环境光强度较高时，调高显示屏1405的显示亮度；当环境光强度较低时，调低显示屏1405的显示亮度。在另一个实施例中，处理器1401还根据光学传感器1415采集的环境光强度，动态调整摄像头组件1406的拍摄参数。

接近传感器1416，也称距离传感器，通常设置在终端1400的前面板。接近传感器1416用于采集用户与终端1400的正面之间的距离。在一个实施例中，当接近传感器1416检测到用户与终端1400的正面之间的距离逐渐变小时，由处理器1401控制显示屏1405从亮屏状态切换为息屏状态；当接近传感器1416检测到用户与终端1400的正面之间的距离逐渐变大时，由处理器1401控制显示屏1405从息屏状态切换为亮屏状态。

本领域技术人员能够理解，图14中示出的结构并不构成对终端1400的限定，能够包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。

图15是本申请实施例提供的一种计算设备的结构示意图，该计算设备1500可因配置或性能不同而产生比较大的差异，该计算设备1500包括一个或一个以上处理器（CentralProcessing Units，CPU）1501和一个或一个以上的存储器1502，其中，该存储器1502中存储有至少一条计算机程序，该至少一条计算机程序由该一个或一个以上处理器1501加载并执行以实现上述各个实施例提供的事务执行方法。可选地，该计算设备1500还具有有线或无线网络接口、键盘以及输入输出接口等部件，以便进行输入输出，该计算设备1500还包括其他用于实现设备功能的部件，在此不做赘述。

在示例性实施例中，还提供了一种计算机可读存储介质，例如包括至少一条计算机程序的存储器，上述至少一条计算机程序可由终端中的处理器执行以完成上述各个实施例中的事务执行方法。例如，该计算机可读存储介质包括ROM（Read-Only Memory，只读存储器）、RAM（Random-Access Memory，随机存取存储器）、CD-ROM（Compact Disc Read-OnlyMemory，只读光盘）、磁带、软盘和光数据存储设备等。

在示例性实施例中，还提供了一种计算机程序产品或计算机程序，包括一条或多条程序代码，该一条或多条程序代码存储在计算机可读存储介质中。计算设备的一个或多个处理器能够从计算机可读存储介质中读取该一条或多条程序代码，该一个或多个处理器执行该一条或多条程序代码，使得计算设备能够执行以完成上述实施例中的事务执行方法。

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

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

Claims (14)

1.一种事务执行方法，其特征在于，所述方法包括：

响应于数据定义语言DDL事务，在DDL事务所操作的数据对象与数据表中的数据列相关联的情况下，确定操作的操作类型；

在解析所述DDL事务所涉及的每一项操作的操作类型时，对操作所涉及的每一个数据对象生成对应的操作解析信息；将所述DDL事务的各项操作所涉及的各个数据对象的所述操作解析信息，存储到操作解析信息集合中；在所述数据表的DDL操作表中，为所述操作解析信息集合中的每一个所述操作解析信息创建一条对应的DDL操作记录；所述DDL操作表用于建立所述数据表中数据记录的不同版本之间的映射关系；所述DDL操作表中的每条所述DDL操作记录都会记载所操作的所述数据对象的版本号，而所述数据表中每条所述数据记录自身存储格式中会携带一个记录版本号，通过在所述DDL操作表中找到位于所述记录版本号到最新版本号之间的所述DDL操作记录，建立出数据记录的存储版本到最新版本之间的映射关系；所述存储版本是指在当前时刻下所述数据表中存储的数据记录对应的版本；

在确定所述DDL事务所操作的所述数据对象所关联的所述数据表后，访问所述数据表的数据字典，在所述数据字典中对所述DDL事务所操作的所述数据对象的定义执行对应的操作，并在对所述数据对象的定义执行所述操作完毕后，提交所述DDL事务；所述数据字典是数据库中用于存放所述数据库中的所述数据对象的定义的地方；

在提交所述DDL事务后，对所述数据列所关联的索引，启动索引修改事务；

响应于所述索引修改事务，对所述数据表中存储的每一条数据记录，若所述数据记录并非最新版本，查询所述数据表的所述DDL操作表，得到所述数据记录从当前版本到所述最新版本之间发生的至少一条DDL操作记录；基于所述至少一条DDL操作记录，生成从所述当前版本到所述最新版本的字段映射关系；基于所述字段映射关系，对所述数据记录的各个字段数据进行映射操作，得到所述最新版本的数据记录，将所述最新版本的所述数据记录写回所述数据表；在所述数据记录所关联的索引记录中，写入所述最新版本的数据记录中与所述索引对应的字段数据，以覆盖已有的同一字段数据；将所述数据表和所述索引均标记为发布状态；其中，所述映射操作包括以下至少一项：若所述DDL操作记录对应的操作类型包括新增列，向新增的数据列对应的字段数据中填充插入值或默认值；若所述DDL操作记录对应的操作类型包括删除列，跳过被删除的数据列对应的字段数据；若所述DDL操作记录对应的操作类型包括修改列位置，将被修改位置的数据列对应的字段数据从原始位置移动至目标位置；若所述DDL操作记录对应的操作类型包括修改列类型，对被修改列类型的数据列对应的字段数据的数据类型从原始类型转换为目标类型；

在所述数据表的所述数据字典中，对所述数据列和所述索引的定义执行所述索引修改事务所指示的修改；将所述DDL事务的跟踪信息置为已完成状态；所述跟踪信息用于跟踪所述DDL事务的执行情况，对所述DDL事务在异常中断后进行恢复执行；

对所述数据表中存储的每一条数据记录，若所述数据记录并非最新版本，且所述数据列的列类型转换存在冲突的情况下，获取所述DDL事务的异常处理参数；在所述异常处理参数指向异常处理函数时，基于所述操作类型下挂载的所述异常处理函数，对所述数据记录进行转换；在所述异常处理参数不指向异常处理函数，或所述异常处理函数对所述数据记录转换失败时，暂停所述索引修改事务，向触发所述DDL事务的设备返回发生冲突的所述数据记录。

2.根据权利要求1所述的方法，其特征在于，所述为所述操作解析信息集合中的每一个所述操作解析信息创建一条对应的DDL操作记录包括：

对每一个数据列的所述操作解析信息，在所述操作解析信息对应的操作类型为增加列的情况下，生成增加所述数据列的DDL操作记录；或，在所述操作解析信息对应的操作类型为删除列的情况下，生成删除所述数据列的DDL操作记录。

3.根据权利要求1所述的方法，其特征在于，所述为所述操作解析信息集合中的每一个所述操作解析信息创建一条对应的DDL操作记录包括：

对每一个数据列的所述操作解析信息，在所述操作解析信息对应的操作类型为修改列的情况下，若所述数据列不具有关联的索引或者所述操作类型不涉及修改所述数据列的列类型，生成修改所述数据列的DDL操作记录。

4.根据权利要求1所述的方法，其特征在于，所述为所述操作解析信息集合中的每一个所述操作解析信息创建一条对应的DDL操作记录包括：

对每一个数据列的所述操作解析信息，在所述操作解析信息对应的操作类型为修改列的情况下，若所述数据列具有关联的索引并且所述操作类型涉及修改所述数据列的列类型，将所述索引标记为仅允许写入状态，将所述数据列所在的数据表标记为检查状态，将所述DDL事务的跟踪信息置为未完成状态；生成修改所述数据列的DDL操作记录。

5.根据权利要求1所述的方法，其特征在于，所述向新增的数据列对应的字段数据中填充默认值，包括：

基于所述DDL事务的默认值设置方式，向所述字段数据中填充符合对应版本的默认值，所述对应版本包括所述数据记录的最新版本或者插入版本。

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

在符合转换条件时，对所述数据库中的每张数据表，调用对应的DDL操作表，将所述数据表中的每条数据记录均转换为最新版本。

7.一种事务执行装置，其特征在于，所述装置包括：

确定模块，用于响应于数据定义语言DDL事务，在DDL事务所操作的数据对象与数据表中的数据列相关联的情况下，确定操作的操作类型；

创建模块，用于在解析所述DDL事务所涉及的每一项操作的操作类型时，对操作所涉及的每一个数据对象生成对应的操作解析信息；将所述DDL事务的各项操作所涉及的各个数据对象的所述操作解析信息，存储到操作解析信息集合中；在所述数据表的DDL操作表中，为所述操作解析信息集合中的每一个所述操作解析信息创建一条对应的DDL操作记录；所述DDL操作表用于建立所述数据表中数据记录的不同版本之间的映射关系；所述DDL操作表中的每条所述DDL操作记录都会记载所操作的所述数据对象的版本号，而所述数据表中每条所述数据记录自身存储格式中会携带一个记录版本号，通过在所述DDL操作表中找到位于所述记录版本号到最新版本号之间的所述DDL操作记录，建立出数据记录的存储版本到最新版本之间的映射关系；所述存储版本是指在当前时刻下所述数据表中存储的数据记录对应的版本；

提交模块，用于在确定所述DDL事务所操作的所述数据对象所关联的所述数据表后，访问所述数据表的数据字典，在所述数据字典中对所述DDL事务所操作的所述数据对象的定义执行对应的操作，并在对所述数据对象的定义执行所述操作完毕后，提交所述DDL事务；所述数据字典是数据库中用于存放所述数据库中的所述数据对象的定义的地方；

启动模块，用于在提交所述DDL事务后，对所述数据列所关联的索引，启动索引修改事务；

修改模块，用于响应于所述索引修改事务，对所述数据表中存储的每一条数据记录，若所述数据记录并非最新版本，查询所述数据表的所述DDL操作表，得到所述数据记录从当前版本到所述最新版本之间发生的至少一条DDL操作记录；基于所述至少一条DDL操作记录，生成从所述当前版本到所述最新版本的字段映射关系；基于所述字段映射关系，对所述数据记录的各个字段数据进行映射操作，得到所述最新版本的数据记录，将所述最新版本的所述数据记录写回所述数据表；

标记模块，用于在所述数据记录所关联的索引记录中，写入所述最新版本的数据记录中与所述索引对应的字段数据，以覆盖已有的同一字段数据；将所述数据表和所述索引均标记为发布状态；其中，所述映射操作包括以下至少一项：若所述DDL操作记录对应的操作类型包括新增列，向新增的数据列对应的字段数据中填充插入值或默认值；若所述DDL操作记录对应的操作类型包括删除列，跳过被删除的数据列对应的字段数据；若所述DDL操作记录对应的操作类型包括修改列位置，将被修改位置的数据列对应的字段数据从原始位置移动至目标位置；若所述DDL操作记录对应的操作类型包括修改列类型，对被修改列类型的数据列对应的字段数据的数据类型从原始类型转换为目标类型；

所述提交模块，用于在所述数据表的所述数据字典中，对所述数据列和所述索引的定义执行所述索引修改事务所指示的修改；

所述标记模块，用于将所述DDL事务的跟踪信息置为已完成状态；所述跟踪信息用于跟踪所述DDL事务的执行情况，对所述DDL事务在异常中断后进行恢复执行；

获取模块，用于对所述数据表中存储的每一条数据记录，若所述数据记录并非最新版本，且所述数据列的列类型转换存在冲突的情况下，获取所述DDL事务的异常处理参数；

第一转换模块，用于在所述异常处理参数指向异常处理函数时，基于所述操作类型下挂载的所述异常处理函数，对所述数据记录进行转换；

返回模块，用于在所述异常处理参数不指向异常处理函数，或所述异常处理函数对所述数据记录转换失败时，暂停所述索引修改事务，向触发所述DDL事务的设备返回发生冲突的所述数据记录。

8.根据权利要求7所述的装置，其特征在于，所述创建模块包括创建单元；

所述创建单元，用于对每一个数据列的所述操作解析信息，在所述操作解析信息对应的操作类型为增加列的情况下，生成增加所述数据列的DDL操作记录；或，在所述操作解析信息对应的操作类型为删除列的情况下，生成删除所述数据列的DDL操作记录。

9.根据权利要求7所述的装置，其特征在于，所述创建模块包括创建单元；

所述创建单元，用于对每一个数据列的所述操作解析信息，在所述操作解析信息对应的操作类型为修改列的情况下，若所述数据列不具有关联的索引或者所述操作类型不涉及修改所述数据列的列类型，生成修改所述数据列的DDL操作记录。

10.根据权利要求7所述的装置，其特征在于，所述创建模块包括创建单元；

所述创建单元，用于对每一个数据列的所述操作解析信息，在所述操作解析信息对应的操作类型为修改列的情况下，若所述数据列具有关联的索引并且所述操作类型涉及修改所述数据列的列类型，将所述索引标记为仅允许写入状态，将所述数据列所在的数据表标记为检查状态，将所述DDL事务的跟踪信息置为未完成状态；生成修改所述数据列的DDL操作记录。

11.根据权利要求7所述的装置，其特征在于，所述修改模块包括映射子单元；

所述映射子单元，用于基于所述DDL事务的默认值设置方式，向所述字段数据中填充符合对应版本的默认值，所述对应版本包括所述数据记录的最新版本或者插入版本。

12.根据权利要求7所述的装置，其特征在于，所述装置还包括第二转换模块；

所述第二转换模块，用于在符合转换条件时，对所述数据库中的每张数据表，调用对应的DDL操作表，将所述数据表中的每条数据记录均转换为最新版本。

13.一种计算设备，其特征在于，所述计算设备包括一个或多个处理器和一个或多个存储器，所述一个或多个存储器中存储有至少一条计算机程序，所述至少一条计算机程序由所述一个或多个处理器加载并执行以实现如权利要求1至权利要求6任一所述的事务执行方法。

14.一种存储介质，其特征在于，所述存储介质中存储有至少一条计算机程序，所述至少一条计算机程序由处理器加载并执行以实现如权利要求1至权利要求6任一所述的事务执行方法。

Images