那海蓝蓝的博客

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

序列化的实现    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)。可恢复性是并发的事务后期、表

可串行化（Serializability）Serializability of a schedule meansequivalence (in the outcome, the database state, data values) to a serialschedule (i.e., sequential with no transaction overlap in time) wit

参考：http://dev.mysql.com/doc/refman/5.7/en/subquery-optimization.html一 引子在上述参考中，有这样的话： The MySQL query optimizer has different strategies available to evaluate subqueries. For IN (o

李海翔，网名“那海蓝蓝”，腾讯金融云，数据库技术专家。    从事数据库研发、数据库架构、数据库技术管理等工作10余年；    历任人北京大金仓研发中心多个项目的技术经理、测试部经理、测试中心总监；    Oracle公司MySQL全球开发组Optimizer Team的核心开发人员；    北京华胜信泰数据技术有限公司，数据库首席架构师，兼研发中心副总经理；    现任职腾讯科技公司，金融云，数

q  两阶段封锁（Two-phase locking - 2PL）：n  首先，两阶段封锁强调的是“加锁（增长阶段，growing phase）和解锁（缩减阶段，shrinking phase）这两项操作，且每项操作各自为一个阶段”，这就是说不管同一个事务内需要在多少个数据项上加锁，那么所有的加锁操作都只能在同一个阶段完成，在这个阶段内，不允许对对已经加锁的数据项进行解锁操作，即加锁和解锁操作

原文：  http://tech.it168.com/a2016/0927/2941/000002941887.shtml做架构的一点心得总结。------------------------------------------【IT168 专稿】一套工具集合，包含7个独立工具、30多万行代码…相信行业内的老司机们都知道小编说的是啥——数据库管理工具。他，从入行到现在，15年里，从数据库管理工具

如果说数据不在ACID特性的保护下会发生不一致的现象，那么：    在ACID的保护下，是不是数据就一定不会产生不一致的现象呢？    在关系数据库系统中，多个会话（session）可以访问同一个数据库的同一个表的同一行数据。这样，对于数据而言，就意味着在同一个时间段内，有多个会话可以对其施加操作（或读操作或写操作），读写操作施加的顺序不同以及事务中A特性对事务结果的影响（或成功或失败，即

支持SSI技术的可序列化的事务的表示    在事务的隔离级别为SERIALIZABLE时，PostgreSQL为支持SSI技术，使用“SERIALIZABLEXACT”表示可序列化的事务，并标识事务与读写冲突之间的关系。typedef struct SERIALIZABLEXACT  // SERIALIZABLEXACT是一个可序列化的事务{   VirtualTransa

3.2 LATERAL连接3.2.1 什么是Lateral连接    我们知道，派生表是非相关的，即不能在派生表里引用其外部的同层次的其他对象。即如下SQL是错误的：select * from t1, (select idx as id2 fromt2 where t2.id2=t1.id1)as temp;temp对象作为一个派生表，其WHERE子句当中出现了“t2.id2=

3.1.3 Q3select * from (select age as age2from test2) as temp,test1;3.1.3.1 ToprowDBQUERY: (OPTIMIZATION TIMESTAMP: 08-15-201618:22:17)------select * from (select age as age2 fromtest2),te

3 深入探讨，一类很少被人关注的子查询3.1 派生表的优化在子查询中，有一类常见的子查询形式，是子查询出现在FROM子句中，这样的子查询，有个学名，叫做“派生表”。这样的且符合SPJ格式要求派生表，可以被优化。这一节，我们来对比四种数据库，看看各个数据库对于派生表的支持情况。大家可以看到，我们将加入Oracle的对比。3.1.1 Q1select * from (select

ToprowDB Dynamic Server 查询优化技术华胜信泰架构师  李海翔（五）ToprowDBDynamic Server 查询优化技术之子查询本篇是《ToprowDB DynamicServer 查询优化技术》系列的第五篇，继续 探讨ToprowDB逻辑查询优化技术中的子查询优化技术。1 还有什么样的子查询，可以被优化？参见上篇《ToprowDB Dyna

今天上午，2016年8月21日，巴西里约奥运会，女排3:1胜对手，打出一场拼搏的精神。----------------------------------------------谓词锁    本节内容介绍谓词锁相关的结构体以及他们之间的关系，谓词锁相关的结构体之间的关系可参见图X-XX。  

1.2.2 PostgreSQL1.2.2.1 S6语句查看查询执行计划，子查询被优化（采用物化的方式，使得子查询结果被缓存，既子查询只执行一次）。postgres=# EXPLAIN SELECT * FROM t3 WHEREb3 >= ANY (SELECT b1 FROM t1); Nested Loop Semi Join  (cost=0.00..41707.39 r

1.2 ANY/SOME/ALL类型的子查询我们进行如下的子查询，分别用S6—S11表示：S6: SELECT * FROM t3 WHERE b3 >= ANY (SELECT b1 FROMt1);S7: SELECT * FROM t3 WHERE b3 >= ANY (SELECT a1 FROMt1);S8: SELECT * FROM t3 WHERE b3 (S

1.1.1 PostgreSQL1.1.2.1  S1语句查看查询执行计划，子查询被优化（采用半连接）。postgres=# EXPLAIN SELECT * FROM t3 WHEREEXISTS (SELECT b1 FROM t1 WHERE a3=a1);                            QUERY PLAN-------------------

ToprowDB Dynamic Server 查询优化技术华胜信泰架构师  李海翔（四）ToprowDBDynamic Server 查询优化技术之子查询本篇是《ToprowDB DynamicServer 查询优化技术》系列的第四篇，继续 探讨ToprowDB逻辑查询优化技术中的子查询优化技术。在第三篇里，初步探讨了子查询优化，接下来次将全面、深入地探讨子查询优化。首先

LWLock在PostgreSQL中的作用    PostgreSQL中，LWLock锁可以加在特定的对象上，如对某个进程加锁，以获取其上锁的状态信息：GetLockStatusData(void){...    for (i =0; i allProcCount; ++i)    {        PGPROC              *proc = &Proc

LWLock释放锁    LWLockRelease()函数释放特定的锁（参数指定的锁）， LWLockReleaseAll()函数调用LWLockRelease()函数完成当前进程持有的（通过“held_lwlocks”持有）所有锁的释放。另外有个LWLockReleaseClearVar()函数配对加锁操作中的LWLockAcquireOrWait()函数使用。voidLWLo

3.2 深入分析—相关子查询细心的读者可以发现，上一节中，我们选取的例子，都是非相关子查询，对于相关的子查询，ToprowDB和MySQL优化器的优化能力又是怎么样的呢？在ToprowDB和MySQL执行同样的查询，用WHERE条件使得子查询为相关子查询，即前面的S4语句：SELECT * FROM t3 WHERE a3 IN (SELECT a1 FROMt1 WHERE b1=

ToprowDB Dynamic Server 查询优化技术（三）ToprowDBDynamic Server 查询优化技术之子查询本篇是《ToprowDB DynamicServer 查询优化技术》系列的第三篇，探讨ToprowDB逻辑查询优化技术中的子查询优化技术。在第二篇里，探讨了视图优化，这一次探讨子查询优化，我们也许会有一些 “故地重游似曾相识”的感觉，感觉子查询

ToprowDB Dynamic Server 查询优化技术华胜信泰架构师  李海翔（二）ToprowDB Dynamic Server 查询优化技术之视图本篇是《ToprowDB Dynamic Server 查询优化技术》系列的第二篇，探讨ToprowDB逻辑查询优化技术中的视图优化技术。视图优化是一个热门技术，在SQL优化技术中，视图优化非常重要。不恰当地使用视图，会造成严重的性能问题，这使

LWLock锁的创建   LWLock用于系统级共享资源的封锁操作，在系统的运行期间，系统级的资源需要加锁，实施操作后，被释放，如缓存区封锁的相关操作即如此。所以LWLock锁需要在整个数据库Server启动期间完成LWLock的准备工作，即被创建好然后再被使用（加锁或解锁）。CreateLWLocks()函数完成共享内存中预留锁的空间的工作，调用InitializeLWLocks()完成锁

LWLock实现的技术    上一节，我们介绍了LWLock的数据结构，其中LWLock锁的“state”上的锁标志可以有两种模式，如下：typedef enum LWLockMode{    LW_EXCLUSIVE,  //排他模式    LW_SHARED,     //共享模式    LW_WAIT_UNTIL_FREE    /* A special mode

LWLock封锁的本质   LWLock的锁操作，符合锁操作的技术本质，加锁同样是设置一个特定的标志位，释放锁是取消标识位。如下以CheckPoint相关操作为例，进行说明，其他类似。   PostgreSQL定义LWLock结构体如下：typedef struct LWLock  //LWLock锁的数据结构，绑定了锁、锁的属主、锁的等待者这三者，PostgreSQL 9.4

表X-XX Wait Event Type Wait Event Name Description Lock[1] relation Waiting to acquire a lock on a relation. extend Waiting to extend

表X-XX Wait Event Type Wait Event Name Description LWLockNamed[1] ShmemIndexLock Waiting to find or allocate space in shared memory. Oid

LWLock   LWLock，轻量锁，主要用于封锁共享内存中的数据结构，以达到互斥访问的目的（避免并发造成的同一份数据被不同进程改写带来的不一致，即一段关键代码同时只允许一个进程进行改写）。   LWLock依赖SpinLock实现，有等待队列但没有死锁检测，能自动释放锁。所以适合使用在封锁时间较短的情况下。    本节从LWLock加锁的本质、LWLock实现的技术、LWLoc

预定义的LWLock锁有42个，具体如下：#define ShmemIndexLock (&MainLWLockArray[1].lock) //共享内存锁#define OidGenLock (&MainLWLockArray[2].lock) //生成Oid的值的锁#define XidGenLock (&MainLWLockArray[3].lock) //生成Xid（事务号

1 创建劝告锁 pg_advisory_lock_int8(PG_FUNCTION_ARGS)//在指定对象上加派他式的劝告锁 {...            SET_LOCKTAG_INT64(tag, key);            (void) LockAcquire(&tag, ExclusiveLock, true, false);...}2 对于诸如

SELECT操作触发的锁    例1，隔离级别为可串行化：BEGIN;SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;SELECT * FROM parent;SELECT * FROM active_locks;COMMIT;    查询active_locks视图，可以得到类似如下的结果，表明在表上增加了一个表级锁“

表级显式锁PostgreSQL提供显式地对表对象加锁，所加的锁在事务结束时（commit或rollback）被释放。LOCK [ TABLE ] [ ONLY ] name [ * ] [, ...] [ INlockmode MODE ] [ NOWAIT ]where lockmode is one of:    ACCESSSHARE | ROW SHARE | RO

MySQL5.6 innodb 数据库引擎。有一个大表A，大约8千万条数据。有个业务场景是从A表选出1千万条数据插入B表，选择语句是走索引的。1)insert into B(id,name) select id,name from A where id in (11,12,13);-- id 上有索引。在这个过程中，线上还有活动业务，有新的数据产生要插入到A表里（B表没有业务访问），大约要插入1千

有朋友问，在MySQL的执行计划中，“DEPENDENT SUBQUERY” 和 “SUBQUERY”到底是什么含义?官方文档解释如下：SUBQUERYFirst