mysql 5.6 5.7 索引 锁_[MySQL5.7] Innodb的索引锁优化-阿里云开发者社区

背景：

.

这是一个臭名昭彰的问题，Innodb的btree发生合并/分裂等可能修改B-tree的操作时，都需要对其加排他的索引锁，这时候是无法对该索引进行读写操作的，极大的影响了性能；关于index lock，可以看看大神Domas的这篇博文：“Innodb locking makes me sad”  以及Vadim的这篇博客

.

总而言之，MySQL5.7.2的这个功能点的改进是万众期待的！

.

以下是阅读Rev6232的笔记，大概理了下关于索引锁优化的几个点。有些只是自己的理解，可能还需要仔细求证； 写的比较乱，同学们慎入- -!!

.

1.新的读写锁类型：SX锁

.

在之前的版本中，Innodb层有两种锁类型，一种是S共享锁，一种是X排他锁，在5.7.2增加了一种新的读写锁类型称为SX共享排他锁，这三类锁的关系为：

| S|SX| X|

–+–+–+–+

S| o| o| x|

–+–+–+–+

SX| o| x| x|

–+–+–+–+

X| x| x| x|

–+–+–+–+

.

S锁和X锁与之前的逻辑相同，没有做变动

SX与SX和X互斥，与S共享，内部定义为RW_SX_LATCH，根据描述，在加上SX锁之后，不会影响读操作，但阻塞写操作

对应的加SX锁接口函数：rw_lock_sx_lock_func ,sx 的 lock_word取值是X lock的一半(X_LOCK_HALF_DECR).LOCK_WORD的范围代表的锁的含义见文件sync/sync0rw.cc的注释

加锁逻辑比较简单，同样使用lock_word来判断，锁之间的冲突关系参阅函数rw_lock_sx_lock_low；加锁失败的话会去做spin，然后再retry，逻辑还是比较简单的。

.

SX的定义感觉有点类似seqlock，读写不阻塞，但写写阻塞；

.

那么目前的逻辑中，有哪些情况要会用到SX锁呢，简单的玩了一下，大概有这么几个地方会用到：

#1

fsp_header_init:

buf_page_get(space, zip_size, 0, RW_SX_LATCH, mtr);

当新create一个表时，会调用这个函数初始化space header，读入第0号page时使用SX lock

.

fsp_header_init->fsp_fill_free_list:

1148                         /* We are going to initialize a new descriptor page

1149                         and a new ibuf bitmap page: the prior contents of the

1150                         pages should be ignored. */

1151

1152                         if (i > 0) {

1153                                 block = buf_page_create(

1154                                         space, i, zip_size, mtr);

1155