Mysql InnoDB存储引擎的锁相关

InnoDB下，mysql四个级别隔离下加锁操作
- 四个级别隔离的写操作都加X锁
- 串行化下读加S锁
- select … for update, select … lock in share mode 分别加x锁，s锁
- 在需要加锁的场景下，会根据情况使用三种加锁策略（算法）
  - Record Lock
  - Gap Lock
  - Next-Key Lock
- mysql RR 为啥能隔离幻读
  - 快照读 select
  - 当前读 select for update, select lock in share mode, delete,insert,update
- InnoDB提供了一致性的非锁定读、行级锁支持
- Lock 与Latch
  - Lock 主要用于锁定数据库中的对象，如表、页、行，而Latch主要是线程并发上的资源锁定。
  - Latch的实现采用了乐观spin-wait,所以在竞争比较激烈的并发环境下，性能不是很好，是一种轻量锁。
  - Latch
    - mutex(互斥liang)
    - rwlock(读写锁）
  - Lock
    - 行锁、表锁、页锁
    - 在没有索引的情况下，一般是锁全表的所有行，然后逐行判断解锁
    - 没有实现锁升级
- 行级锁
  - 共享锁（S Lock)
  - 排他锁 (X Lock)
  - S与S兼容，而X与什么都不兼容
- 意向锁（事务在更细的粒度上加锁）
  - 意向共享锁(IS Lock) ,事务想要获得一张表中某几行的共享锁
  - 意向排他锁(IX Lock),事务想要获得一张表中某几行的排他锁
  - InnoDB的意向锁是表级别的锁
- 一致性的非锁定读
  - 通过行多版本控制的方式来读取当前执行时间数据中行的数据。
  - 如果当前行的X锁已经被获得，那么通过undo 段，来获得X锁被获得前的快照，返回该快照的数据
  - 非锁定读，不需要X锁的释放就可以进行操作。可以等同于在事务开始时获得全局快照，在事务运行期间，无论其他事务是否对数据进行提交，都不影响。
- 一致性锁定读
  - SELECT…FOR UPDATE （加X锁)
  - SELECT… LOCK IN SHARE MODE (加S锁)
- 自增长与锁
  - SELECT MAX(auto_inc_col) FROM t FOR UPDATE;
- 外键和锁
  - 对外键值的插入和更新的时候，需要读父表，这时不能采用一致的非锁定读，否则会出现子表与父表不一致的现象。所以需要采用一致性读，也就是给父表加S锁。
- 行锁的三种算法
  - Record Lock: 单个行记录上的锁
    - 锁的是索引，如果没有设置索引，那么锁的是主键
  - Gap Lock: 间隙锁，锁定一个范围，不包含记录本身
    *
  - Next-Key Lock: Gap Lock + Record Lock, 锁定一个范围，并且锁定记录本身
    - 唯一索引情况下，降级为Record Lock
- InnoDB通过Next-key Lock避免了幻读问题
  - 通过加两个间隙锁，来保证对于insert,delete操作不会造成幻读
- 所有隔离级别都实现了写写互斥
- 四种隔离级别
  - 读未提交
    - 读读不互斥、读写不互斥、写写互斥（不是没有加锁！！！！）
  - 读已提交（一致性的非锁定读）
    - 读读不互斥、读写不互斥、写写互斥
    - 每次读都是读的最新快照（避免了脏读，通过undo log实现）
  - 可重复读（一致性的非锁定读）
    - 读读不互斥、读写不互斥、写写互斥
    - 每次读都是事务开始时的最新快照（避免了脏读，不可重复读，通过undo log实现）
  - 串行化
    - 读读不互斥、读写互斥、写写互斥
    - 读读加的是S锁
    - 容易发生死锁
- 死锁
  - 发生死锁时，会自动回滚事务

Mysql Innodb 中的锁

先列出我本地的运行环境

数据库版本是5.7，隔离级别是Repeatable-Read(可重复读)，不同的数据库版本和隔离级别对语句的执行结果影响很大。讨论锁的时候不指明版本和隔离级别，都是耍流氓。

一、为什么要加锁

数据库是一个多用户使用的共享资源。当多个用户并发地存取数据时，在数据库中就会产生多个事务同时存取同一数据的情况。若对并发操作不加控制就可能会读取和存储不正确的数据，破坏数据库的一致性。

锁是用于管理对公共资源的并发控制。也就是说并发的情况下，会出现资源竞争，所以需要加锁。

举个例子，转账操作。简单来说，张三给李四转账x元，可以分为三步：

1，先查询张三的账户余额y是否大于x2，张三的余额 y = y - x元3，李四的余额 x = z + x元

假设张三账户余额有1000元，李四余额也有1000元，如果不加锁的话，同时有两个请求，A要求转500元，B要求转600元，第一步查询余额都是足够的，第2步和第3步也能执行成功，但是最终结果却是错误，第二个请求可能会覆盖掉第一个请求。

这种问题叫做 丢失更新：多个事务操作同一行，后面的更新覆盖了前面的更新值。需要在应用级别加锁来避免。

数据库有ACID原则，其中I是隔离性，标准SQL规范中定义了四种隔离级别：

越往下，隔离级别越高，问题越少，同时并发度也越低。隔离级别和并发度成反比的。

脏读：事务A读取了事务B未提交的数据
不可重复读：对于一条记录，事务A两次读取的数据变了
幻读：事务A按照相同的查询条件，读取到了新增的数据

MySQL中的隔离级别如下：

和标准SQL规范相比，MySQL中可重复读解决了幻读，实现了串行化隔离级别的功能，同时没有严重影响并发。是通过加锁、阻止插入新数据，来解决幻读的。

二、锁的分类

我们听说过读锁、写锁、共享锁、互斥锁、行锁等等各种名词，根据自己的理解，简单对这些锁进行了分类。

加锁机制：

1、乐观锁：先修改，保存时判断是够被更新过，应用级别

2、悲观锁：先获取锁，再操作修改，数据库级别

锁粒度：

表级锁：开销小，加锁快，粒度大，锁冲突概率大，并发度低，适用于读多写少的情况。

页级锁：BDB存储引擎

行级锁：Innodb存储引擎，默认选项

兼容性：

S锁，也叫做读锁、共享锁，对应于我们常用的 select * from users where id =1 lock in share mode

X锁，也叫做写锁、排它锁、独占锁、互斥锁，对应对于select * from users where id =1 for update

下面这个表格是锁冲突矩阵，可以看到只有读锁和读锁之间兼容的，写锁和读锁、写锁都是冲突的。

冲突的时候会阻塞当前会话，直到拿到锁或者超时

这里要提到的一点是，S锁和 X锁是可以是表锁，也可以是行锁

索引组织表

先理解下索引组织表。

辅助索引

聚集索引

Innodb中的索引数据结构是 B+ 树，数据是有序排列的，从根节点到叶子节点一层层找到对应的数据。普通索引，也叫做辅助索引，叶子节点存放的是主键值。主键上的索引叫做聚集索引，表里的每一条记录都存放在主键的叶子节点上。当通过辅助索引select 查询数据的时候，会先在辅助索引中找到对应的主键值，然后用主键值在聚集索引中找到该条记录。举个例子，用name=Alice来查询的时候，会先找到对应的主键值是18 ，然后用18在下面的聚集索引中找到name=Alice的记录内容是 77 和 Alice。

表中每一行的数据，是组织存放在聚集索引中的，所以叫做索引组织表。

了解索引数据结构的目的是为了说明，行锁是加在索引上的。

1.select * from user where id=10 for update

一条简单的SQL。在user表中查找id为10的记录，并用for update加X锁。

这里User表中，有3个字段，主键id 和另外一个字段name。下面的表格是B+树索引的简化表达。第一行id是索引的节点，第二行和第三行是这行记录，包含了姓名和性别。

如图所示，通过锁住聚集索引中的节点来锁住这条记录。

聚集索引上的锁，比较好理解，锁住id=10的索引，即锁住了这条记录。

2. select * from user where name=‘b’ for update

查询user表中name为d的记录，并用for update加X锁

这里的name上加了唯一索引，唯一索引本质上是辅助索引，加了唯一约束。所以会先在辅助索引上找到name为d的索引记录，在辅助索引中加锁，然后查找聚集索引，锁住对应索引记录。

为什么聚簇索引上的记录也要加锁？试想一下，如果有并发的另外一个SQL，是直接通过主键索引id=30来更新，会先在聚集索引中请求加锁。如果只在辅助索引中加锁的话，两个并发SQL之间是互相感知不到的。

3. select * from user where name=‘b’ for update

查询user表中name为b的记录，并用for update加X锁。这里name上加了普通的索引，不是唯一索引。普通索引的值是可以重复的。会先在辅助索引中找到name为b的两条记录，加X锁，然后得到主键值7和30，到聚集索引中加X锁。

事情并没有那么简单，如果这时有另一个事务，插入了name=b,id=40的记录，却发现是可以插入的。

位置在途中红色线条标注的间隙内，这样就会出现幻读，两次查询得到的结果是不一致的，第一次查到两条数据，插入之后得到三条数据。

为了防止这种情况，出现了另一种锁，gap lcok 间隙锁。锁住的是索引的间隙。

即图中，红色线条标识的空隙。因为新插入name=b的记录，可能出现在这三个间隙内。

这张图里出现了三种锁

记录锁：单行记录上的锁

间隙锁：锁定记录之间的范围，但不包含记录本身。

Next Key Lock: 记录锁+ 间隙锁，锁定一个范围，包含记录本身。

4. 意向锁( Intention Locks )

InnoDB为了支持多粒度(表锁与行锁)的锁并存，引入意向锁。意向锁是表级锁，

IS: 意向共享锁
IX: 意向排他锁

事务在请求某一行的S锁和X锁前，需要先获得对应表的IS、IX锁。

意向锁产生的主要目的是为了处理行锁和表锁之间的冲突，用于表明“某个事务正在某一行上持有了锁，或者准备去持有锁”。比如，表中的某一行上加了X锁，就不能对这张表加X锁。

如果不在表上加意向锁，对表加锁的时候，都要去检查表中的某一行上是否加有行锁，多麻烦。

意向锁的兼容性矩阵

5. 插入意向锁（Insert Intention Lock）

Gap Lock中存在一种插入意向锁，在insert操作时产生。

有两个作用：

和next-key互斥，阻塞next-key 锁，防止插入数据，这样就不会幻读。
插入意向锁互相是兼容的，允许相同间隙、不同数据的并发插入

三、常见语句的加锁分析

后面会有多个SQL语句，先说明一下表结构

CREATE TABLE `user` (`id` int(11) unsigned NOT NULL AUTO_INCREMENT,`id_no` varchar(255) DEFAULT NULL COMMENT '身份证号',`name` varchar(255) DEFAULT NULL COMMENT '姓名',`mobile` varchar(255) DEFAULT NULL COMMENT '手机号',`age` int(11) DEFAULT NULL COMMENT '年龄',`address` varchar(255) DEFAULT NULL COMMENT '地址',PRIMARY KEY (`id`),UNIQUE KEY `uniq_id_no` (`id_no`),KEY `idx_name` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=10002 DEFAULT CHARSET=utf8 COMMENT='用户表';

这里有一个user表，5个字段，其中id是主键，id_no是身份证号，加了唯一索引，name是用户姓名，可以重复的，加了普通索引，手机号、年龄、地址都没有索引。

1. 普通select

select  * from user where id =1;begin;
select  * from user where id =1;
commit:

普通的select 语句是不加锁的。select包裹在事务中，同样也是不加锁的。where后面的条件不管多少，普通的select是不加锁的。

2. 显式加锁

select  * from user where id =1 lock in share mode;select  * from user where id =1 for update;

显式指出要加什么样的锁。上面一个加的是共享锁，下面的是互斥锁。

这里需要强调的一点，需要明确在事务中是用这些锁，不在事务中是没有意义的。

3. 隐式加锁

update user set address '北京' where id=1;
delete from user where id=1;

update和delete也会对查询出的记录加X锁，隐式加互斥锁。加锁类型和for update 类似

后面只按照显式加锁的select for update 举例子，更新和删除的加锁方式是一样的。

4. 按索引类型

elect  * from user where id =1 for update;select  * from user where id_no ='a22' for update;select  * from user where name ='王二' for update;select  * from user where address ='杭州' for update;

四条SQL，区别在于where条件的过滤列，分别是主键、唯一索引、普通索引、无索引。

主键：之前提到过索引组织表，这里会在聚集索引上对查询出的记录，加X锁

唯一索引：会在辅助索引上，把在对应的id_no=a22的索引加X锁，因为是唯一的，所以不是next-key锁。然后在主键上，也会在这条记录上加X锁。

普通索引：因为不是唯一的，会在辅助索引上，把对应的id_no=a22的索引加next-key锁。然后在主键加X锁。

无索引：首先，是不推荐这种写法，没有索引的话，因为会全表扫描，数据量大的话查询会很慢。这里讨论的是，这种情况下，会加什么锁？答案：首先，聚簇索引上的所有记录，都被加上了X锁。其次，聚簇索引每条记录间的间隙(GAP)，也同时被加上了GAP锁。在这种情况下，这个表上，除了不加锁的快照度，其他任何加锁的并发SQL，均不能执行，不能更新，不能删除，不能插入，全表被锁死。这是一个很恐怖的事情，请注意。

5. 记录不存在的情况

前面几个例子中，都是可以查到结果的。如果对应记录不存在会怎样？答案是锁住间隙，不允许插入。mysql要保证没有其他人可以插入，所以锁住间隙。

6. 普通 insert 语句

在插入之前，会先在插入记录所在的间隙加上一个插入意向锁。

insert会对插入成功的行加上排它锁，这个排它锁是个记录锁，而非next-key锁（当然更不是gap锁了），不会阻止其他并发的事务往这条记录之前插入。

7. 先查询后插入

类似于这样的insert

insert into target_table select * from source_table ...
create target_table select * from source_table ...

将select查询的结果集，插入到另一张表中，或者使用结果集，创建一个新表。

和之前简单插入的情况类似，已插入成功的数据加X锁，间隙加上一个插入意向锁。

对于select的源表中的记录，会加共享的 next-key 锁。这是为了防止主从同步出问题。

举个例子：

session1 先开启事务，然后查询user2表的结果集，插入到user表中，session2开启事务，在插入user2中插入数据，所插入的数据刚好是session1能查询到的数据，如果不加锁的话，session2可以插入成功，然后session2提交事务，接着session1提交数据。这样看起来是没问题的，但是session2先提交的，所以bin log中会这样记录，先在user2表中插入数据，然后在user中插入数据，这样的bin log在从库执行的时候，就会出问题。

主库： user2插入一条数据，user 插入一条数据

从库： user2插入一条数据，user 插入两条数据

user表会比主库多一条数据。所以需要锁住select查询表中加next-key锁，不允许user2表中新增数据。

四、分析当前锁的情况

先说一下死锁的定义，死锁是指两个或两个以上的事务在执行过程中，因争夺资源而造成的一种互相等待的现象。这个定义适用于数据库，有几个重点，两个或两个以上的事务，一个事务是不会出现死锁的。争夺的资源一般都是表或者记录。

出现死锁了会怎样，正常情况下，mysql会检查出死锁，并回滚某一个事务，让另一个事务正常运行。

Mysql 会回滚副作用小的事务，判定的标准是执行的时间以及影响的范围。

1.如何知道系统有没有发生过死锁，如何去查看发生过的锁

show status like ‘innodb_row_lock%'; 从系统启动到现在的数据

Innodb_row_lock_current_waits：当前正在等待锁的数量；

Innodb_row_lock_time ：锁定的总时间长度，单位ms；

Innodb_row_lock_time_avg ：每次等待所花平均时间；

Innodb_row_lock_time_max：从系统启动到现在等待最长的一次所花的时间；

Innodb_row_lock_waits ：从系统启动到现在总共等待的次数。

平均时间和锁等待次数比较大的话，说明可能会存在锁争用情况

2. show engine innodb status

展示innodb存储引擎的运行状态

通过这个命令显示的内容比较多，其中有一项lasted detected deadlock 显示最近发生的死锁。

图中红色线条标注的是执行的SQL，以及加了什么锁，可以看出是在这行记录上加了X锁，没有gap锁。

3. 错误日志中查看历史发生过的死锁

set global innodb_print_all_deadlocks=1;

上一个命令，只能看到最近发生的锁，如果我想看历史发生的锁怎么办？执行这一句，更改innodb 的一个配置，innodb_print_all_deadlocks，打印所有的死锁。会将死锁的信息输出到mysql的错误日志中，默认是不输出，格式和show engine innodb status 是差不多的。

4. information_schema.innodb_locks