## 前言 InnoDB并发过程中使用两类锁进行同步。 1\. 事务锁 维护在不同的Isolation level下数据库的Atomicity和Consistency两大基本特性。 InnoDB定义了如下的lock mode: ~~~ /* Basic lock modes */ enum lock_mode { LOCK_IS = 0, /* intention shared */ LOCK_IX, /* intention exclusive */ LOCK_S, /* shared */ LOCK_X, /* exclusive */ LOCK_AUTO_INC, /* locks the auto-inc counter of a table in an exclusive mode */ LOCK_NONE, /* this is used elsewhere to note consistent read */ LOCK_NUM = LOCK_NONE, /* number of lock modes */ LOCK_NONE_UNSET = 255 }; ~~~ 2\. 内存锁 为了维护内存结构的一致性,比如Dictionary cache、sync array、trx system等结构。 InnoDB并没有直接使用glibc提供的库,而是自己封装了两类: 1\. 一类是mutex,实现内存结构的串行化访问 2\. 一类是rw lock,实现读写阻塞,读读并发的访问的读写锁 读者如果有兴趣,可以直接翻阅InnoDB的代码,这里我们主要介绍index lock所使用的rw lock。 ## InnoDB index lock InnoDB默认使用B-Tree结构来保存数据,如下图所示的B-Tree结构: ![InnoDB B-Tree结构](https://box.kancloud.cn/2015-09-24_56039b2f4ba52.png "InnoDB B-Tree") 这个B-Tree一共有两类节点,一类是node(branch) block,一类是leaf block,对于内存中的每一个block,都有一个rw lock与之相对应,用于保护block内部结构的一致性,阻塞并发修改。每一个index在内存中保持着一个index字典对象,即`dict_index_t`,并对应着一个index lock,同样属于rw lock类型,用于保护B-Tree的平衡树结构。 所以,InnoDB为每一个index,维护两种rw lock: 1\. index级别的,用于保护B-Tree结构不被破坏 2\. block级别的,用于保护block内部结构不被破坏 很明显,rw lock 锁保护的对象的级别越高,冲突的可能性就越大,并发的瓶颈也就越容易出现。 ## InnoDB index lock的处理场景分析 1. 我们先来看rw lock的模型,rw lock一共使用两类lock mode,即S锁和X锁,其相容性矩阵是: ~~~ | S| X| --+--+--+ S | o| x| --+--+--+ X | x| x| --+--+--+ ~~~ 按照lock mode,数据库对B-Tree操作区分几种类型: ~~~ btr_search_leaf btr_modify_leaf btr_modify_tree btr_search_prev btr_modify_prev ~~~ 根据这些不同的操作类型,我们下面来分析一下加锁的过程。 ## 场景分析 ### 场景1\. 索引扫描查询 如果sql通过索引进行扫描,其latch mode为`btr_search_leaf`: 首先是hold住index lock的RW_S_LATCH,然后通过`btr_cur_search_to_nth_level`进行B-Tree查询leaf节点的过程。当cursor定位到leaf节点上之后,在leaf page节点上,添加RW_S_LATCH锁,即S锁,然后通过save_point的mtr释放index lock的S锁。在扫描的过程中,因为持有index的RW_S_LATCH,所以节点的扫描比如root、branch这样的node block,并不持有任何mode的rw lock。直到latch住leaf节点后,就释放掉 index 的锁,这样尽可能的减少阻塞,剩下就是leaf节点的扫描过程,只持有leaf page的锁。 扫描完数据,就释放leaf page的S锁。 ### 场景2\. 升序和降序查询 场景2和场景1在持有index lock的过程中,是相同的,都是在search的过程中,持有RW_S_LATCH,一旦定位到leaf page,就释放掉index 的S锁,升序和降序的扫描过程中,会沿着leaf page之间的双链表进行扫描,因为是双向链表,所以可以完成asc和desc的扫描。但这里要注意的是,InnoDB先持有下一个page的lock,然后再释放当前持有page的lock,这样就有可能造成死锁,所以InnoDB不管当前是asc还是desc的扫描,都会先持有左leaf page的lock,然后再持有下一个leaf page的锁,最后释放prev page的lock,这样做到加锁的顺序一致,避免死锁。 ### 场景3\. 乐观插入记录 InnoDB在插入记录的过程中,分了两个步骤,乐观插入和悲观插入: 1\. 乐观,就是当前leaf page的剩余空间满足记录的插入需要; 2\. 悲观,就是需要split B-Tree,增加leaf page来完成新记录的插入。 先看乐观插入: 场景1和场景2都持有leaf page的RW_S_LATCH,但在插入的过程中,操作类型是btr_modify_leaf,需要持有leaf page的RW_X_LATCH, 在search的过程中,和场景1、2相同,都是持有index的RW_S_LATCH lock,一旦定位结束,释放index lock。 ### 场景4\. 悲观插入记录 悲观插入,需要split B-Tree,所以首先会持有index lock,mode为RW_X_LATCH,并X lock三个leaf page,即prev,current,next三个leaf page,然后修改branch节点的记录,指向leaf节点,修改完成后,才能释放index lock。 在split的过程中,无法进行search操作(因为正在修改branch节点),但如果其他线程已经在读取leaf page,并不会受影响。 ### 场景5\. online DDL 在online DDL的过程中,比如add index,因为是新添加的index,并不会产生并发访问的问题。 ### 场景6\. DDL 比如加字段的过程,其并发问题,由server层的MDL锁和InnoDB层的事务锁来完成其同步。 ## 问题: 我们来看上面提到的6个场景,对我们日常使用InnoDB的过程中,影响最大的就是场景4,即split的过程中,会严重的影响并发,因为index 的X lock,导致任何的B-Tree扫描都产生了阻塞。有解吗? 通常我们碰到lock导致的并发问题的时候,第一个想到的就是降低锁对象的粒度,粒度越小,共享区域也就越小,冲突的几率也就越小,并发就能够提高。 根据这个原则,我们回过头来看这个问题,因为index lock 保护了整个B-Tree的结构,但我们对某一个branch节点进行split的时候,我们仅仅修改了这个branch节点,所以我们可以把锁的粒度降低到某些要修改的branch节点上,这样就可以不影响其他branch节点的扫描和访问。 ## MySQL 5.7的改进 MySQL官方对index lock进行了优化,在split的过程中,尽可能的减少冲突,减少并发的瓶颈。 对于InnoDB的rw lock增加第三种lock mode,即SX锁,其相容性矩阵如下: ~~~ | S|SX| X| --+--+--+--+ S | o| o| x| --+--+--+--+ SX| o| x| x| --+--+--+--+ X | x| x| x| --+--+--+--+ ~~~ 这里仍然保留了index lock,考虑一下两个存在冲突的场景,还是否阻塞: 1\. BTR_SEARCH_LEAF和BTR_MODIFY_LEAF 对于扫描leaf节点和修改leaf节点的场景: ~~~ index->lock 持有S锁不变 branch->latch 从无--> S latch latch order: latch root block (S) latch root-1 block (S) .... latch leaf+1 block (S) leaf->latch 持有S或者X锁不变 release index lock 不变 release branch latch 从无到释放 ~~~ 和之前的差别是在search的过程中,对使用到的branch节点,加上S锁,用于同步branch节点的修改。同样,当定位到leaf节点后,就可以把index lock和branch lock全部释放掉了,后面leaf节点之间的移动,同样不需要index lock和branch lock。 2\. BTR_MODIFY_TREE 对于修改index B-Tree结构的场景: ~~~ index->lock 从X锁-->SX 锁 branch->latch 从无--> X latch ~~~ 注意:因为有index SX锁,所以不允许并发的修改B-Tree操作,所以,只需要X latch要修改的branch即可。 和之前的差别就是index lock从X锁变成了SX锁,这样并不影响search的过程,增加了更改过程中branch节点的X锁。 ## 总结: 这样修改后,index lock在并发的过程中,修改B-Tree和search B-Tree没有了并发冲突问题,在split的过程中,只有search和modify到同一个branch节点,才会产生阻塞,对于我们正常的使用数据库过程中(大部分都是通过index进行读写),可以显著的提升并发能力。