MySQL：锁机制 |表级锁、行级锁 | 排它锁、共享锁 | 间隙锁

表级锁&行级锁

表级锁：对整张表加锁。开销小，加锁快，不会出现死锁；锁粒度大，发生锁冲突的概率高，并发度
低。
行级锁：对某行记录加锁。开销大，加锁慢，会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并
发度高。

示例：

排它锁 & 共享锁

排它锁（Exclusive），又称为X 锁，写锁。
共享锁（Shared），又称为S 锁，读锁。
X和S锁之间有以下的关系： SS可以兼容的，XS、SX、XX之间是互斥的

一个事务对数据对象 O 加了 S 锁，可以对 O 进行读取操作但不能进行更新操作。加锁期间其它事
务能对O 加 S 锁但不能加 X 锁。
一个事务对数据对象 O 加了 X 锁，就可以对 O 进行读取和更新。加锁期间其它事务不能对 O 加任
何锁。

显示加锁：select … lock in share mode强制获取共享锁，select … for update获取排它锁

排它锁示例：

使用select… for update; 获取id为5的行的排它锁

在另一个客户端上开启事务，再想获得这一行的排它锁，就会阻塞住，超时后返回错误码。

表锁的示例：

先来看user表的创建过程，主键是id，另外还有个age字段也是索引。

如果使用非索引的字段来获取锁：

这时候在另一个客户端来获取排它锁或共享锁，发现都被阻塞住了。。

原因：

InnoDB的行锁是加在索引项上面的，是给索引在加锁，并不是给单纯的行记录在加锁，如果过滤条件没有索引的话，使用的就是表锁，而不是行锁。

InnoDB行级锁

InnoDB存储引擎支持事务处理，表支持行级锁定，并发能力更好。

1、InnoDB行锁是通过给索引上的索引项加锁来实现的，而不是给表的行记录加锁实现的，这就意味着只有通过索引条件检索数据，InnoDB才使用行级锁，否则InnoDB将使用表锁。
2、由于InnoDB的行锁实现是针对索引字段添加的锁，不是针对行记录加的锁，因此虽然访问的是
InnoDB引擎下表的不同行，但是如果使用相同的索引字段作为过滤条件，依然会发生锁冲突，只能串行进行，不能并发进行。
3、即使SQL中使用了索引，但是经过MySQL的优化器后，如果认为全表扫描比使用索引效率更高，此时会放弃使用索引，因此也不会使用行锁，而是使用表锁，比如对一些很小的表，MySQL就不会去使用索引。

间隙锁——解决幻读

当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB 会给符合条件的已有数据记录的索引项加锁；对于键值在条件范围内但并不存在的记录，叫做“间隙（GAP)” ，InnoDB 也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁。举例来说， 假如 user 表中只有 101 条记录， 其
userid 的值分别是 1,2,…,100,101， 下面的 SQL：

select * from user where userid > 100 for update;

是一个范围条件的检索，InnoDB 不仅会对符合条件的 userid 值为 101 的记录加锁，也会对userid 大
于 101（但是这些记录并不存在）的"间隙"加锁，防止其它事务在表的末尾增加数据。
InnoDB使用间隙锁的目的，为了防止幻读，以满足串行化隔离级别的要求，对于上面的例子，要是不使用间隙锁，如果其他事务插入了 userid 大于 100 的任何记录，那么本事务如果再次执行上述语句，就会发生幻读。

如果遇到这种问题：
串行化隔离级别怎么解决幻读问题的？

另一个事务想增加数据，是会阻塞住的，原因就是存在间隙锁，获取不到锁。

再来看一个示例：

在另一个事务里，插入age为22、21、20都会被阻塞

原因，先来看看表里的数据，和对应的索引树，红框就表示有间隙锁的存在，新插入的数据如果在这些范围内，就不允许插入。