## 前言 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结构：  这个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进行读写），可以显著的提升并发能力。