还需要补充一点，当主键索引和唯一索引直接命中的时候，如下图所示，InnoDB除了给a = 5这行数据加了行锁，还可能给(5, 5)这个间隙加了间隙锁，这样的说法听起来很奇怪。
因为事务A是给a = 5这行数据加了行锁，而行锁只能针对已经存在的数据，不能加到即将插入的数据上；此外，当事务A执行这条语句的时候，事务B是会被阻塞的。直到事务A提交，事务B才会提示唯一索引重复。也就是说，在事务B执行这行语句的时候，是无法访问id = 5这行数据的，事务B不知道id = 5到底存不存在。
所以我才说：当索引直接命中的时候，还会加上这么一个小小的间隙锁。我没有查到这方面的资料，如果你能解释的话，请留言告诉我。
2.4 普通索引对于普通索引来说，与唯一索引最大的区别，就是普通索引不是必须唯一的，也就是说，当插入数据的时候，可能会有重复的情况。
而在上面的内容中我们也发现了一个规律：InnoDB的间隙锁，就是为了防止新插入的数据影响查找结果。
所以对于普通索引来说，还需要防止新插入的数据和原数据一样的情况（因为唯一索引不需要担心这么一种情况）。
下面我们举例说明，在此之前先插入一行数据：
insert into t values(8,8,5,8);那么此时我们的索引b，是这样的：
因为是非唯一索引的原因，在两个b = 5的间隙，也能插入数据。
如图所示，我们这次把查找条件换成了b = 5。此时，我们插入的数据id = 1，理论上应该要插入(0,5)这个间隙内，但是由于间隙锁的存在，插入将被阻塞。
换一句话说，只要此时插入的数据b = 5，那么就一定无法插入。
而对于未命中的条件，规则和上文中说到的一样，根据查找条件的最小值往前找到第一个一个索引，再根据这个条件的最大值往后找到第一个索引，构成间隙锁的范围。
此外，与唯一索引一样，所有命中的数据行，都会回表将主键id也锁住。
2.5 无索引可以看到，我们的查找条件是c = 5，直接命中了数据。此时我们插入的数据是c = 6，看起来和事务A无关，但是出乎意料的是，事务B还是会被阻塞。
直接说结论：对于不含有索引的查找项来说，会锁住所有的间隙和所有的数据。
关于幻读的问题的一些case，到这里就研究完了（但是我不确定有没有遗漏，如果有，还请你留言告诉我）。
在最后还需要说一个概念，行锁与间隔锁，合称next-key lock。并且需要注意的是，只有在可重复读的事务隔离级别中，才会有间隔锁。并且可重复读是遵循两阶段锁协议，所有加锁的资源，都是在事务提交或者回滚的时候才释放的。所以，在防止幻读产生的时候，同样降低了并发度。
3 表级锁在上一节说完了行级锁之后，我们再来聊聊表级锁。
表级锁有两种，一种是显式添加的，一种是隐式添加的。
3.1 读写表锁还记得我们在上文中提到的读锁和写锁的特点吗，这点在表锁中是一样的。
给表加上了写锁，意味着只有这个会话拥有读写这个表的权限；给表加上了读锁，才能读取这个表上的数据，并且可以多个线程共享读锁，但是，只有当某个表上没有读锁时，才能给这个表加上写锁。
下面是给表加锁的语法：
lock tables table_name read lock tables table_name write 3.2 MDLMDL指的是（Metadata Lock），指的是元数据锁。
MDL也分为了读锁和写锁，功能和上面提到的一样。
只不过MDL不需要像表锁那样显式的使用，它会在访问一个表的时候会被自动加上。其中，在某个表对数据进行操作（包括insert,delete,update,select）的时候，会隐式的加上MDL读锁，在修改表的结构的时候，会加上写锁。