索引并发(蟹行协议和B-Link树)

索引并发

事务的并发问题可以通过两阶段封锁协议（2PL）或者多版本并发控制（mvcc）等方法解决。这些方法也同样适用于索引的并发访问控制。但是，由于索引访问频繁，它们将成为封锁竞争的集中点，导致低并发度。对事务而言，对一个索引查找两次，并在期间发现索引结构发生变化，这是完全可以接受的，只要索引查找返回正确的元组集。因此，只要维护索引的准确性，对索引进行非可串行化井发存取是可接受的。

蟹行协议

● 当搜索一条记录时，蟹行协议先用共享锁锁住根节点。然后尝试获取子节点的共享锁，获得子节点共享锁后，释放父节点上的锁，重复这个过程知道搜索到叶节点。
● 当插入或删除一条记录时：

1、采取与查找相同的方法，知道找到目标叶节点，到此为止，它只获得（或释放）共享锁。

2、用排它锁封锁该叶节点，插入或者删除记录。

3、如果需要分裂一个结点或将它与兄弟结点合并，或者在兄弟之间重新分配记录来平衡B+树，蟹行协议用排他锁封锁父结点。在完成这些操作后，它释放该结点和兄弟结点的锁。如果父结点需要分裂、合并或重新分布记录，协议保留父结点上的锁，以同样方式分裂、合并或重新分布记录，并且传播更远。否则，协议释放父结点的锁。

该协议的名字来源于螃蟹走路的方式:先移动一边的腿，然后移动另一条腿。如此交替进行，就像螃蟹移动一样。
向下的搜索操作和由于分裂、合并或重新分布记录而向上传播的封锁操作之间有可能出现死锁，系统能很容易地处理这种