内存并发控制
为了维护内存结构的一致性，比如Dictionary cache、sync array、trx system等结构。
InnoDB并没有直接使用glibc提供的库，而是自己封装了两类：
- 一类是mutex，实现内存结构的串行化访问。
- 一类是rw lock，实现读写阻塞，读读并发的访问的读写锁。
B+树并发控制
B+树的并发控制主要分2个方面，一个是节点中内容的并发控制、另一个是树结构的并发控制，比如树高的变化、页的分裂等等。
为了实现上述两方面的并发控制。
5.6版本
InnoDB为每一个index，维护两种rw lock:
- index级别的，用于保护B-Tree结构不被破坏。
- block级别的，用于保护block内部结构不被破坏，仅适用于叶子节点，非叶子节点不加锁。
rw lock分为S、X两种模式，如果设计到SMO，需要对index级别的rw lock加X锁，这样的实现带来的好处是代码实现非常简单, 但是缺点也很明显由于在SMO 操作的过程中, 读取操作也是无法进行的, 并且SMO 操作过程可能有IO 操作, 带来的性能抖动非常明显
具体参考http://mysql.taobao.org/monthly/2020/06/02/
5.7版本
主要有这两个改动
- rw-lock引入了sx模式，优化了阻塞读的问题。
- block级别的rw-lock，非叶子几点也加锁。
S、X、SX三个模式的兼容关系如下：
/*
LOCK COMPATIBILITY MATRIX
S SX X
S + + -
SX + - -
X - - -
*/
加锁的具体流程：
- 如果是一个查询请求
- 那么首先把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/
