与海翔新书作序海翔在数据库管理系统领域的第二本著作《数据库事务处理的艺术：事务管理与并发控制》马上就要出版了，他邀请我写个序，我没有犹豫就欣然答应了。事后，我自己都觉得奇怪会这么痛快，但细细想来，还是有充分理由的。这个序得写！首先，我对在数据库核心技术领域长期辛勤耕耘的人表示尊敬。数据库是信息系统的基础和核心，对数据库实现技术是否真正掌握关系到我国在信息技术核心领域的自主可控战略是

序列化的实现    InnoDB对于序列化的实现方式，是通过两种方式实现的。    第一种，当SELECT语句在一个显式的事务块内，如执行表11-9中的编号为1的情况，将施加LOCK_S锁，根据表11-6（记录锁事务锁相容表）可知，LOCK_S锁排斥写锁，所以序列化隔离级别下只允许并发地读取操作，并发写被禁止，因此实现了可序列化（参见1.2.2节）。相应代码如下：ha_innoba

可重复读的实现    可重复读隔离级别，简称RR，在2.1.1节，我们说过：    Repeatable Read（可重复读）：一个事务在执行过程中可以看到其他事务已经提交的新插入的记录（读已经提交的，其实是读早于本事务开始且已经提交的），但是不能看到其他事务对已有记录的更新（即晚于本事务开始的），并且，该事务不要求与其他事务是“可串行化”的。    这句话的核心，是“但是不能看到其他

对于读已提交隔离级别的实现方式，从逻辑上需要明确两个部分，一是加锁部分二是解锁部分。加锁，对应的是获取数据，确保在指定的隔离级别下读取到应该读到的数据。解锁则意味着要在适当的时机释放锁且不影响隔离级别的语义还能提高并发度。    加锁部分，实现分为两个方面：一是加锁的时候，读已提交隔离级别不加间隙锁，这样就能允许并发的其他事务执行插入操作因而产生幻象现象，因为读已提交隔离级别是允许幻象异常存在

读未提交的实现    对于读未提交隔离级别，此级别不会对记录加锁，有如下几种情况：1 对系统表的数据操作，是数据引擎自己发出的数据查询操作，使用读未提交隔离级别，目的是不与其它事务因锁的存在而冲突。2 在row_search_mvcc()、row_sel_get_clust_rec_for_mysql()等获取记录的函数中确保读未提交隔离级别下允许读到最新的记录。   那么，

1 元数据锁的锁请求与锁等待    元数据锁在MySQL Server层，按照锁的状态被细分为两种，一种是已经施加的锁，一种是等待施加的锁即锁请求，这样被区分的原因，如MySQL对“class MDL_request”的代码注释作了解释：/**  A pendingmetadata lock request.   A lockrequest and a granted

MySQLServer层定义了如下的元数据锁的粒度，这些锁较多，超出了读锁和写锁两种锁粒度，这是因为读锁和写锁通常是理论上根据概念探讨的范畴，而在工程实践中会根据实际情况进行细化，以最大限度地提高并发度。/**    Type ofmetadata lock request.    @saComments for MDL_object_lock::can_grant_lock

事务的实现，在不同的数据库系统中是不同的，这是因为事务有着不同的模型，在Jim Gray的《事务处理概念与技术》一书的第四章事务模型中，把事务分为：q  平板事务（Flat Transactions）：事务块中的所有SQL语句，构成一个逻辑单元，要么都成功，要么因之一失败都回滚。PostgreSQL的事务管理如果不考虑保存点（Savepoint）机制，可以认为就是一个平板类型的事务，事务块内的

InnoDB定义的Mutex的作用    在许多对象（如数据缓冲区、字典表、系统锁表、双写缓冲区等）上、在许多操作作用的对象（如事务、回滚段等）上，InnoDB都定义了很多系统锁，用以保护某个对象。这些系统锁，就是上一节讨论的Mutex。定义好的Mutex的具体作用，详情参见表11-5。 表11-5 InnoDB的系统级锁 类别 锁的名称

InnoDB定义的Mutex    InnoDB在ib0mutex.h文件中定义了六种自定义的Mutex如下：q OSBasicMutex：OS的Event定义的Mutex，依赖于具体的OS；施加锁只尝试一次。如下面的初始化代码段等。q OSTrackMutex：继承自OSBasicMutex，依赖于OS；施加锁尝试函数参数指定的次数（max_spins参数指定尝试的次数）。q

四 深入讨论：什么是“事务提交”？    在标题三中，我们认为InnoDB不符合预写日志机制，这是基于事务提交的标志设置是在刷出日志之前完成的，这一点，是基于InnoDB的代码实现的意图来下的结论。InnoDB认为在内存的状态设置了提交标志就算是“事务提交”完成了。    但是，传统的数据库理论认为，“事务提交”需要符合持久性（ACID之D），也就是说，事务的最后一个记录输出到稳定存储介质

三 为什么说InnoDB不符合WAL预写日志机制？    在标题二中我们提出这样的一个调用栈：innobase_commit_low(trx)    -> trx_commit_for_mysql()        -> trx_commit(trx)            ->trx_commit_low()               ->  trx_commi

当事务正常执行结束时，事务的提交操作，是实现事务原子性的主要操作之一，这个过程很重要。如下我们重点分析事务提交过程中一些重要环节。 一 事务提交的整体过程    InnoDB和MySQL Server联合实现了事务的提交全程，相关过程参见表10-2，在这个表里面，从上到下，是一个事务提交过程的栈，上面是栈顶下面是栈底，底层的函数调用了上层的函数。 表10-2 事务提交的相关函数

事务通过trx_rsegs_t与系统表空间和临时表空间等物理存储联系起来的方式如下：/** Rollback segments assigned to a transaction forundo logging. */struct trx_rsegs_t{    /** undolog ptr holding reference to a rollback segment t

直观感觉，一个事务花费很长时间不能够结束，就是一个长的事务，简称长事务( Long Transaction )。在OLTP类型的数据库系统中，一个事务的执行时间通常会很短，所以不会感觉其执行时间漫长。长事务的概念不一而足：在Oracle中，运行时间超过6秒的事务就被视为长事务。Informix把占用整个逻辑日志空间在一定比例以上的事务（事务占用整个逻辑日志空间的百分比超过“长事务深水线比例”这

1 Orca框架结构1.1 Orca与database的关系  图一 Orca与数据的关系图 1.2 Orca内部架构 图二Orca内部架构图 说明：图一和图二源自Orca:A Modular Query Optimizer Architecture for Big Data 2 基本对象2.1 作业2.1.1作业Job的概念一个Job，可

├─cmake              构建相关├─data               测试数据├─libgpdbcost        代价模型│  ├─include│  │  └─gpdbcost│  └─src├─libgpopt│  ├─include         头文件│  │  └─gpopt        ...│  └─src│      ├─base        实现

严格性（Strictness）    A schedule is strict - has the strictness property - if for any twotransactions T1, T2, if a write operation of T1 precedes a conflictingoperation of T2 (either read or write),

可恢复性（Recoverability）Recoverability means that committedtransactions have not read data written by aborted transactions (whose effectsdo not exist in the resulting database states)。可恢复性是并发的事务后期、表