Innodb-B+树-并发控制

内存并发控制

为了维护内存结构的一致性，比如Dictionary cache、sync array、trx system等结构。
InnoDB并没有直接使用glibc提供的库，而是自己封装了两类：

1. 一类是mutex，实现内存结构的串行化访问。
2. 一类是rw lock，实现读写阻塞，读读并发的访问的读写锁。

B+树并发控制

B+树的并发控制主要分2个方面，一个是节点中内容的并发控制、另一个是树结构的并发控制，比如树高的变化、页的分裂等等。
为了实现上述两方面的并发控制。

5.6版本

InnoDB为每一个index，维护两种rw lock:

1. index级别的，用于保护B-Tree结构不被破坏。
2. block级别的，用于保护block内部结构不被破坏，仅适用于叶子节点，非叶子节点不加锁。

rw lock分为S、X两种模式，如果设计到SMO，需要对index级别的rw lock加X锁，这样的实现带来的好处是代码实现非常简单, 但是缺点也很明显由于在SMO 操作的过程中, 读取操作也是无法进行的, 并且SMO 操作过程可能有IO 操作, 带来的性能抖动非常明显
具体参考http://mysql.taobao.org/monthly/2020/06/02/

5.7版本

主要有这两个改动

1. rw-lock引入了sx模式，优化了阻塞读的问题。
2. block级别的rw-lock，非叶子几点也加锁。
   S、X、SX三个模式的兼容关系如下：

/*
 LOCK COMPATIBILITY MATRIX
    S SX  X
 S  +  +  -
 SX +  -  -
 X  -  -  -
 */

加锁的具体流程：

1. 如果是一个查询请求

• 那么首先把btree index->lock S LOCK
• 然后沿着搜索btree 路径, 遇到的non-leaf node page 都加 S LOCK
• 然后直到找到 leaf node 以后, 对leaft node page 也是 S LOCK, 然后把index-> lock 放开
  
  image.png
  
  2.修改请求的流程也参见http://mysql.taobao.org/monthly/2020/06/02/
  这个page 的修改是否会引起 btree 的变化？
• 如果不会, 那么很好, 对leaf node 执行了X LOCK 以后, 修改完数据返回就可以
• 如果会, 那么需要执行悲观插入操作, 重新遍历btree. 这时候给index->lock 是加 SX LOCK。
  因为已经给btree 加上sx lock, 那么搜索路径上的btree 的page 都不需要加 lock, 但是需要把搜索过程中的page 保存下来, 最后阶段给搜索路径上有可能发生结构变化的page 加x lock。
  这样就保证了在搜索的过程中, 对于read 操作的影响降到最低。
  只有在最后阶段确定了本次修改btree 结构的范围, 对可能发生结构变化的page 加X lock 以后, 才会有影响。

代码实现

B树的搜索入口函数为btr_cur_search_to_nth_level，其参数latch_mode分为两部分，低字节为如下的基本操作模式：

/** Latching modes for btr_cur_search_to_nth_level(). */
enum btr_latch_mode {
    /** Search a record on a leaf page and S-latch it. */
    BTR_SEARCH_LEAF = RW_S_LATCH,
    /** (Prepare to) modify a record on a leaf page and X-latch it. */
    BTR_MODIFY_LEAF = RW_X_LATCH,
    /** Obtain no latches. */
    BTR_NO_LATCHES = RW_NO_LATCH,
    /** Start modifying the entire B-tree. */
    BTR_MODIFY_TREE = 33,
    /** Continue modifying the entire B-tree. */
    BTR_CONT_MODIFY_TREE = 34,
    /** Search the previous record. */
    BTR_SEARCH_PREV = 35,
    /** Modify the previous record. */
    BTR_MODIFY_PREV = 36,
    /** Start searching the entire B-tree. */
    BTR_SEARCH_TREE = 37,
    /** Continue searching the entire B-tree. */
    BTR_CONT_SEARCH_TREE = 38
};

每种模式的加锁流程可以参考：https://zhuanlan.zhihu.com/p/164705538

悲观写入

悲观写入因为会涉及SMO,所以需要重新遍历B Tree加锁

row_ins_clust_index_entry
//这里是BTR_MODIFY_LEAF
----row_ins_clust_index_entry_low(flags, BTR_MODIFY_LEAF, index, n_uniq, entry, n_ext, thr, dup_chk_only)
--------btr_pcur_open //调用btr_cur_search_to_nth_level 查询索引树，将cursor移动到待插入记录相应的位置
------------btr_cur_optimistic_insert //乐观插入
//如果插入失败需要遍历B树，此时是BTR_MODIFY_TREE
----row_ins_clust_index_entry_low(flags, BTR_MODIFY_TREE, index, n_uniq, entry, n_ext, thr, dup_chk_only)
--------btr_pcur_open //调用btr_cur_search_to_nth_level 查询索引树，将cursor移动到待插入记录相应的位置
-----------btr_cur_optimistic_insert //乐观插入
-----------btr_cur_pessimistic_insert //悲观插入

http://static.kancloud.cn/taobaomysql/monthly/67063
http://mysql.taobao.org/monthly/2020/06/02/
https://zhuanlan.zhihu.com/p/164705538
http://liuyangming.tech/07-2019/InnoDB-Lock.html#insert%E7%9A%84rwlock
http://mysql.taobao.org/monthly/2017/10/03/
http://mysql.taobao.org/monthly/2018/09/01/