一、隐式锁

一个事务在执行INSERT操作时，如果即将插入的间隙已经被其他事务加了gap锁，那么本次INSERT操作会阻塞，并且当前事务会在该间隙上加一个插入意向锁，否则一般情况下INSERT操作是不加锁的。如果一个事务首先插入了一条记录（此时并没有在内存生产与该记录关联的锁结构），然后另一个事务：
情况1、立即使用SELECT . . . FOR SHARE语句读取这条记录，也就是要获取这条记录的S 锁，或者使用SELECT . . . FOR UPDATE语句读取这条记录，也就是要获取这条记录的X锁，怎么办？如果允许这种情况的发生，那么可能产生脏读问题
情况2、立即修改这条记录，也就是要获取这条记录的X 锁，怎么办？如果允许这种情况的发生，那么可能产生脏写问题。
这时候事务id要起作用了。把聚簇索引和二级索引中的记录分开来分析

1、情景一：聚簇索引

对于聚簇索引记录来说，有一个 trx_id 隐藏列，该隐藏列记录着最后改动改记录的事务id。那么如果在当前事务中新插入一条聚簇索引记录后，该记录的trx_id隐藏列代表的就是当前事务的事务id，如果其他事务此时想对该记录添加 S 锁 或者 X 锁时，首先会看一下该记录的 trx_id 隐藏列代表的事务是否时当前的活跃事务，如果是，那么就帮助当前事务创建一个X锁（也就是为当前事务创建一个锁结构，is_waiting属性是 false），然后自己进入等待状态（也就是为自己也创建一个锁结构，is_waiting属性是 true）

2、情景二：二级索引

对于二级索引记录来说，本身并没有trx_id隐藏列，但是在二级索引页面的Page Header部分有一个PAGE_MAX_TRX_ID属性，该属性代表对该页面做改动的最大的事务id，如果PAGE_MAX_TRX_ID属性值小于当前最小的活跃事务id，说明对该页面做修改的事务都已经提交了，否则就需要在页面中定位到对应的二级索引记录，然后回表找到它对应的聚簇索引记录，然后再重复情景一的做法

3、小结

一个事务对新插入的记录可以不显示的加锁（生成一个锁结构），但是由于事务id的存在，相当于加了一个隐式锁。别的事务在对这条记录加S锁或者X锁时，由于隐式锁的存在，会先帮助当前事务生成一个锁结构，然后自己再生成一个锁结构后进入等待状态。隐式锁是一种延迟加锁的机制，从而来减少加锁的数量。
隐式锁在实际内存对象中并不含有这个锁信息。只有当产生锁等待时，隐式锁转化为显式锁。

4、实战

InnoDB的INSERT操作，对插入的记录不加锁，但是此时如果另一个线程进行当前读，会怎样？

• Session1

BEGIN ;

SELECT *
FROM student;

INSERT INTO student
    VALUE (4, 'Raven', '三班');

• Session2

BEGIN ;

SELECT *
FROM student FOR SHARE ;

image.png

• 查看锁信息

SELECT *
FROM performance_schema.data_lock_waits;

小结：隐式锁的逻辑过程

• A、InnoDB的每条记录中都一个隐含的trx_id字段，这个字段存在于聚簇索引的B+Tree中。
• B、在操作一条记录前，首先根据记录中的trx_id检查该事务是否是活动的事务(未提交或回滚)。如果是活动的事务，首先将 隐式锁转换为 显式锁 (就是为该事务添加一个锁)。
• C、检查是否有锁冲突，如果有冲突，创建锁，并设置为waiting状态。如果没有冲突不加锁，跳到E。
• D、等待加锁成功，被唤醒，或者超时。
• E、写数据，并将自己的trx_id写入trx_id字段。

二、 显式锁

通过特定的语句进行加锁，我们一般称之为显示加锁

• 显示加共享锁

SELECT . . . FOR SHARE 

• 显示加排它锁

SELECT . . . FOR UPDATE 

三、全局锁

全局锁就是对 整个数据库实例 加锁。当你需要让整个库处于 只读状态 的时候，可以使用这个命令，之后其他线程的以下语句会被阻塞：
1、数据更新语句（数据的增删改）
2、数据定义语句（包括建表、修改表结构等）和更新类事务的提交语句。
全局锁的典型使用 场景 是：做 全库逻辑备份。

• 全局锁的命令

Flush tables with read lock

四、死锁

死锁是指两个或多个事务在同一资源上相互占用，并请求锁定对方占用的资源，从而导致恶性循环。两个事务都持有对方需要的锁，并且在等待对方释放，并且双方都不会释放自己的锁

1、实战1

image.png

2、小结

这时候，事务1在等待事务2释放id=2的行锁，而事务2在等待事务1释放id=1的行锁。 事务1和事务2在互相等待对方的资源释放，就是进入了死锁状态。当出现死锁以后，有 两种策略 ：

• 一种策略是，直接进入等待，直到超时。这个超时时间可以通过参数innodb_lock_wait_timeout 来设置。
• 另一种策略是，发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务（将持有最少行级排他锁的事务进行回滚），让其他事务得以继续执行。将参数 innodb_deadlock_detect 设置为on ，表示开启这个逻辑。

4、产生死锁的必要条件：两个（或以上）的 Session加锁的顺序不一致

• 1、2个或者2个以上事务
• 2、每个事务都已经持有锁并且申请新的锁
• 3、锁资源同时只能被同一个事务持有或者不兼容
• 4、事务之间因为持有锁和申请锁导致彼此循环等待

5、处理死锁

5.1、方式1-等待，直到超时（Innodb_lock_wait_timeout=50s）

当两个事务互相等待时，当一个事务等待时间超过设置的阈值时，就将其回滚，另外事务继续进行。这种方法简单有效，在InnoDB中，参数Innodb_lock_wait_timeout用来设置超时时间。
缺点：对于在线服务来说，这个等待时间往往是无法接受的
如果将该参数修改短一些，如1s，0.1s是不合适，容易吴伤到普通的锁等待

5.2、方式2-使用死锁检测进行死锁处理

方式1检测死锁太过被动，InnoDB还提供了wait-for graph 算法来主动进行死锁检测，每当加锁请求无法立即满足需要并进入等待时，wait-for graph 算法都会被触发。这是一种较为主动的死锁检测机制，要求数据库保存锁的信息链表和事务等待链表两部分信息

• wait-for graph 算法 wait-for graph 算法.png

• 基于这两个信息，可以绘制wait-for graph等待图

死锁检测的原理是构建一个以事务为顶点、锁位边的有向图，判断有向图是否存在环，存在即有死锁。一旦检测到回路、有死锁，这时候InnoDB存储引擎会选择回滚 undo 量最小的事务，让其他事务继续执行(innodb_deadlock_detect=on表示开启这个逻辑)

等待图.png

• 死锁检测缺点：每个新的被阻塞的线程，都需要判断是不是由于自己的加入导致了死锁，这个操作时间复杂度是O(n)。如果100个并发线程同时更新同一行，意味着样检查100*100=1万次，1万个线程就会有1千万次检测

5.3、解决 死锁

5.3.1、方式1

关闭死锁检测，但意味着可能会出现大量的超时，会导致业务有损

5.3.1、方式2

控制并发访问的数量。比如在中间件中实现对于相同行的更新，在进入引擎之前排队，这样在InnoDB内部就不会有大量的死锁检测工作

5.4、第二种策略的成本分析

方法1：关闭死锁检测

如果能确保这个业务一定不会出现死锁，可以临时把死锁检测关掉。但是这种操作本身带有一定的风险，因为业务设计的时候一般不会把死锁当做一个严重错误，毕竟出现死锁了，就回滚，然后通过业务重试一般就没问题了，这是 业务无损 的。而关掉死锁检测意味着可能会出现大量的超时，这是业务有损 的。

方法2：控制并发度

如果并发能够控制住，比如同一行同时最多只有10个线程在更新，那么死锁检测的成本很低，就不会出现这个问题。
这个并发控制要做在 数据库服务端 。如果你有中间件，可以考虑在 中间件实现 ；甚至有能力修改MySQL源码的人，也可以做在MySQL里面。基本思路就是，对于相同行的更新，在进入引擎之前排队，这样在InnoDB内部就不会有大量的死锁检测工作了。

6、小结：避免死锁

• 合理设计索引，使业务 SQL 尽可能通过索引定位更少的行，减少锁竞争
• 调整业务逻辑 SQL 执行顺序，避免 UPDATE / DELETE长时间持有锁的 SQL 在事务前面
• 避免大事务，尽量将大事务拆成多个小事务来处理，小事务缩短锁定资源的时间，发生锁冲突的几率也更小
• 在并发比较高的系统中，不要显示加锁，特别是是在事务里显示加锁。如SELECT . . . FOR UPDATE语句，如果是在事务里运行了 Start Transaction 或设置了 autocommit = 0，那么就会锁定所查找到的记录
• 降低隔离级别。如果业务允许，将隔离级别调低也是较好的选择，比如将隔离级别从RR调整为RC，可以避免掉很多因为gap锁造成的死锁