InnoDB中的锁

虽然锁机制是InnoDB引擎中为了保证事务性而自然存在的，在索引、表结构、配置参数一定的前提下，InnoDB引擎加锁过程是一样的，所以理论上来说也就不存在锁机制能够提升性能”这样的说法。但如果技术人员不理解InnoDB中的锁机制或者混乱、错误的索引定义和同样混乱的SQL写操作语句共同作用，那么导致死锁出现的可能性就越大，需要InnoDB进行死锁检测的情况就越多，最终导致不必要的性能浪费甚至事务执行失败。所以理解InnoDB引擎中的锁机制可以帮助我们在高并发系统中尽可能不让锁和死锁成为数据库服务的一个性能瓶颈
InnoDB中的锁类型
本文讲解的锁机制主要依据MySQL Version 5.6以及之前的版本（这是目前线上环境使用最多的版本），在MySQL Version 5.7以及最新的MySQL 8.0中InnoDB引擎的锁类型发生了一些变化（后文会提及），但基本思路没有变化。InnoDB引擎中的锁类型按照独占形式可以分为共享锁和排它锁（还有意向性共享锁和意向性排它锁）；**按照锁定数据的范围可以分为行级锁（其它引擎中还有页级锁的定义）、间隙锁、间隙复合锁？？和表锁；**为了保证锁的粒度能够至上而下传递，InnoDB中还设计有不能被用户干预的意向共享锁和意向排它锁。
共享锁（S锁）
由于InnoDB引擎支持事务，所以需要锁机制在多个事务同时工作时保证每个事务的ACID特性。共享锁的特性是多个事务可以同时为某个资源加锁后进行读操作，并且这些事务间不会出现相互等待的现象

排它锁（X锁）
排它锁又被称为独占锁，一旦某个事务对资源加排它锁，其它事务就不能再为这个资源加共享锁或者排它锁了。一直要等待到当前的独占锁从资源上解除后，才能继续对资源进行操作。排它锁只会影响其他事务的加锁操作，也就是说如果其它事务只是使用简单的SELECT查询语句检索资源，就不会受到影响，因为这些SELECT查询语句不会试图为资源加任何锁，也就不会受资源上已有的排它锁的影响。我们可以用一张表表示排它锁和共享锁的互斥关系

排它锁和共享锁的互斥关系
行级锁（Record lock）
行级锁是InnoDB引擎中对锁的最小支持粒度，即是指这个锁可以锁定数据表中某一个具体的数据行，锁的类型可以是排它锁也可以是共享锁。例如读者可以在两个独立事务中同时使用以下语句查询指定的行，但是两个事务并不会相互等待：

# lock in share mode 是为满足查询条件的数据行加共享锁
# 注意它和直接使用select语句的不同特性
select * from myuser where id = 6 lock in share mode;

间隙锁（GAP锁）

间隙锁只有在特定事务级别下才会使用，具体来说是“可重复读”（Repeatable Read ）这样的事务级别，这也是InnoDB引擎默认的事务级别，它的大致解释是无论在这个事务中执行多少次相同语句的当前读操作，其每次读取的记录内容都是一样的，并不受外部事务操作的影响。间隙锁主要为了防止多个事务在交叉工作的情况下，特别是同时进行数据插入的情况下出现幻读。举一个简单的例子，事务A中的操作正在执行以下update语句的操作：

# 事务A正在执行一个范围内数据的更新操作
# 大意是说将用户会员卡号序列大于10的所有记录中user_name字段全部更新为一个新的值
update myuser set user_name = '用户11' where user_number >= 10;

其中user_number带有一个索引（后续我们将讨论这个索引类型对间隙锁策略的影响），这样的检索条件很显然会涉及到一个范围的数据都将被更新（例如user_number==10、13、15、17、19、21……），于此同时有另一个事务B正在执行以下语句

......
# 事务B正在执行一个插入操作
insert into myuser(.........,'user_number') values (.........,11);
# 插入一个卡号为11的新会员，然后提交事务B
......

如果InnoDB只锁住user_number值为10的非聚簇索引和相应的聚簇索引，显然就会造成一个问题：在A事务处理过程中，突然多出了一条满足更新条件的记录。事务A会很纠结的，很尴尬的。如果读者是InnoDB引擎的开发者，您会怎么做呢？正确的做法是为满足事务A所执行检索条件的整个范围加锁，这个锁不是加在某个或某几个具体的记录上，因为那样做还是无法限制类似插入“一个卡号为11的新纪录”这样的情况，而是加在到具体索引和下一个索引之间，告诉这个索引B+树的其它使用者，包括这个索引在内的之后区域都不允许使用。这样的锁机制称为间隙锁（GAP锁）。

间隙锁和行级锁组合起来称为Next-Key Lock，实际上这两种锁一般情况下都是组合工作的。

表级锁：
没有可以检索的索引，就无法使用InnoDB特定的锁。另外，索引失效InnoDB也会为整个数据表加锁。如果表级锁的性质是排它锁（实际上大多数情况是这样的锁），那么所有试图为这张数据表中任何资源加共享锁或者排它锁的事务都必须等待在数据表上的排它锁被解除后，才能继续工作。表级锁可以看作基于InnoDB引擎工作的数据表的最悲观锁，它是InnoDB引擎为了保持事务特性的一场豪赌。

uid（PK） varchar
user_name varchar
user_sex int

这张数据表中只有一个由uid字段构成的主索引。接着两个事务同时执行以下语句

begin;
select * from t_user where uid = 2 lock in share mode;
#都先不执行commit，以便观察现象
#commit;

这里的select查询虽然使用的检索依据是uid，但是设置检索条件时uid的varchar类型却被错误的使用成了int类型。那么数据表将不再使用索引进行检索，转而进行全表扫秒。这是一种典型的索引失效情况，最终读者观察到的现象是，在执行以上同一查询语句的两个事务中，有一个返回了查询结果，但是另外一个一直为等待状态。以上的小例子也可以让读者看到，科学管理索引在InnoDB引擎中是何等重要。本文后续部分将向读者介绍表级锁的实质结构。
意向共享锁（IS锁）和意向排它锁（IX锁）
为了在某一个具体索引上加共享锁，事务需要首先为涉及到的数据表加意向共享锁（IS锁）；为了在某一个具体索引上加排它锁，事务需要首先为涉及到的数据表加意向排它锁（IX锁）。这样InnoDB可以整体把握在并发的若干个事务中，让哪些事务优先执行更能产生好的执行效果。意向共享锁是InnoDB引擎自动控制的，开发人员无法人工干预，也不需要干预。