MySQL锁机制
文章目录
1. 概述
事务的 隔离性 由 锁 来实现。为保证数据的一致性，需要对 并发操作进行控制 ，因此产生了 锁 。同时 锁机制 也为实现MySQL的各个隔离级别提供了保证。 锁冲突 也是影响数据库 并发访问性能 的一个重要因素。所以锁对数据库而言显得尤其重要，也更加复杂
2. MySQL并发事务访问相同记录
并发事务访问相同记录的情况大致可以划分为3种：
2.1 读-读情况
读-读 情况，即并发事务相继 读取相同的记录 。读取操作本身不会对记录有任何影响，并不会引起什么问题，所以允许这种情况的发生。
2.2 写-写情况
写-写 情况，即并发事务相继对相同的记录做出改动。可能会存在 脏写 情况。在MySQL中任何隔离级别都不会存在 脏写 情况。MySQL底层使用类似Java synchronized的锁机制来解决该问题，使事务排队执行。
2.3 读-写或写-读情况
读-写 或 写-读 ，即一个事务进行读取操作，另一个进行改动操作。这种情况下可能发生 脏读 、 不可重复读 、 幻读 的问题。
各个数据库厂商对 SQL标准 的支持都可能不一样。比如MySQL在 REPEATABLE READ 隔离级别上就已经解决了 幻读 问题。
2.4 并发问题的解决方案
- 方案一：读操作利用多版本并发控制（
MVCC，下章讲解），写操作进行加锁；采用MVCC方式的话，读-写操作彼此并不冲突，性能更高
MVCC，就是生成一个Readview，通过ReadView找到符合条件的记录版本(历史版本由 undo日志构建)。查询语句只能 读 到在生成ReadView之前 已提交事务所做的更改，在生成ReadView之前未提交的事务或者之后才开启的事务所做的更改是看不到的。而 写操作 肯定针对的是 最新版本的记录，读记录的历史版本和改动记录的最新版本本身并不冲突，也就是采用MVCC时，读-写 操作并不冲突
普通的SELECT语句在READ COMMITTED和REPEATABLE READ隔离级别下会使用到MVCC读取记录。
- 在
READ COMMITTED隔离级别下，一个事务在执行过程中每次执行SELECT操作时都会生成一个ReadView，ReadView的存在本身就保证了事务不可以读取到未提交的事务所做的更改，也就是避免了脏读现象；- 在
REPEATABLE READ隔离级别下，一个事务在执行过程中只有第一次执行SELECT操作才会生成一个ReadView，之后的SELECT操作都复用这个ReadView，这样也就避免了不可重复读和幻读的问题。
- 方案二：读、写操作都采用
加锁的方式；采用加锁方式的话，读-写操作彼此需要排队执行，影响性能
一般情况下我们当然愿意采用 MVCC 来解决 读-写 操作并发执行的问题，但是业务在某些特殊情况下，要求必须采用 加锁 的方式执行。下面就讲解下MySQL中不同类别的锁
3. 锁的不同角度分类
3.1 从数据操作的类型划分：读锁、写锁
读锁（Read Lock） ：也称为共享锁（Share Lock，S Lock） 、英文用 S 表示。针对同一份数据，多个事务的读操作可以同时进行而不会互相影响，相互不阻塞的。写锁（Write Lock）：也称为排他锁（Exclusive Lock、X Lock）、英文用 X 表示。当前写操作没有完成前，它会阻断其他写锁和读锁。这样就能确保在给定的时间里，只有一个事务能执行写入，并防止其他用户读取正在写入的同一资源
需要注意的是对于 InnoDB 引擎来说，读锁和写锁可以加在表上，也可以加在行上。
1. 锁定读
- 对读取的记录加
S锁；加 S 锁后其他事务不可对这些记录加 X 锁，必须等 S 锁释放。
select ... lock in share mode;
# 或
select ... for share; #(8.0新增语法)
- 对记录加
X锁；加 X 锁后，其他事务既不可以锁定读，也不可以修改这些数据，必须等 X 锁释放。
select ... for update;
MySQL 8.0新特性
在之前版本，select ... for update; 获取不到锁，会一直等待，直到 innodb_lock_wait_timeout （默认50，单位秒）超时，在8.0中，可在末尾加如下关键字：
NOWAIT：如果查询的行已经加锁，立即报错返回SKIP LOCKED：如果查询的行已经加锁，立即返回，只是返回的结果中不包含被锁定的行
2. 写操作
-
DELETE：对一条记录做DELETE操作的过程其实是先在
B+树中定位到这条记录的位置，然后获取这条记录的X锁，再执行delete mark操作。可以把这个定位待删除记录在B+树中位置的过程看成是一个获取X锁的锁定读。 -
INSERT：一般情况下，新插入一条记录的操作并不加锁，通过一种称之为
隐式锁的结构来保护这条新插入的记录在本事务提交前不被别的事务访问。 -
UPDATE：在对一条记录做UPDATE操作时分为三种情况：-
情况1: 未修改该记录的键值，并且被更新的列占用的存储空间在修改前后未发生变化
先在 B+ 树中定位到这条记录的位置，然后获取记录的 X锁，最后在原记录的位置进行修改操作。
-
情况2: 未修改该记录的键值，并且至少有一个被更新的列占用的存储空间在修改前后发生变化
先在 B+ 树中定位到这条记录的位置，然后获取记录的 X锁，将该记录彻底删除掉(就是把记录彻底移入垃圾链表)，最后再插入一条新记录。这个定位待修改记录在 B+ 树中位置的过程看成是一个获取
X锁的锁定读，新插入的记录由INSERT操作提供的隐式锁进行保护 -
情况3: 修改了该记录的键值
相当于在原记录上做DELETE 操作之后再来一次 INSERT 操作，加锁操作按照 DELETE 和 INSERT 的规则进行
-
3.2 从数据操作的粒度划分：表级锁、页级锁、行锁
1. 表锁（Table Lock）
查看表锁
show open tables where In_use > 0;
（1）表级别的 S 锁、X 锁
MySQL的表级锁有两种模式：
- 表共享读锁（Table Read Lock）
- 表独占写锁（Table Write Lock）
一般不会使用Innodb提供的表级别的 S 锁和 X 锁，只会在一些特殊情况下，比方说 崩溃恢复 过程中用到。InnoDB的厉害之处还是实现了更细粒度的 行锁。
（2）意向锁 （intention lock）
InnoDB 支持 多粒度锁（multiple granularity locking） ，它允许 行级锁 与 表级锁 共存，而意向锁就是其中的一种 表锁 。
如果我们给某一行数据加上了排它锁，数据库会自动给更大一级的空间，比如数据页或数据表加上意向锁，告诉其他人这个数据页或数据表已经有人上过排它锁了，这样当其他人想要获取数据表排它锁的时候，只需要了解是否有人已经获取了这个数据表的意向排他锁即可，而无需逐行遍历是否有行锁。
-
意向共享锁（intention shared lock, IS）：事务有意向对表中的某些行加共享锁（S锁）
-- 事务要获取某些行的 S 锁，必须先获得表的 IS 锁。 SELECT column FROM table ... LOCK IN SHARE MODE; -
意向排他锁（intention exclusive lock, IX）：事务有意向对表中的某些行加排他锁（X锁）
-- 事务要获取某些行的 X 锁，必须先获得表的 IX 锁。 SELECT column FROM table ... FOR UPDATE;
即：意向锁是由存储引擎 自己维护的 ，用户无法手动操作意向锁，在为数据行加共享 / 排他锁之前，InooDB 会先获取该数据行 所在数据表的对应意向锁 。
小结：
- InnoDB 支持
多粒度锁，特定场景下，行级锁可以与表级锁共存 - 意向锁之间互不排斥，也不会和行级的 X 锁、S 锁发生冲突，但会和表级别的 S锁 和 X 锁互斥
- 意向锁在保证并发性的前提下，实现了
行锁和表锁共存且满足事务隔离性的要求
（3）自增锁（AUTO-INC锁）
首先需了解插入数据的方式总共分为三类，分别是
-
“Simple inserts” （简单插入）可以
预先确定要插入的行数（当语句被初始处理时）的语句。包括没有嵌套子查询的单行和多行INSERT...VALUES()和REPLACE语句。比如我们上面举的例子就属于该类插入，已经确定要插入的行数。 -
“Bulk inserts” （批量插入）
事先不知道要插入的行数 （和所需自动递增值的数量）的语句。比如 INSERT ... SELECT ， REPLACE... SELECT 和 LOAD DATA 语句，但不包括纯INSERT。 InnoDB在每处理一行，为AUTO_INCREMENT列分配一个新值。
-
“Mixed-mode inserts” （混合模式插入）这些是“Simple inserts”语句但是指定部分新行的自动递增值。例如
INSERT INTO teacher (id,name) VALUES (1,'a'), (NULL,'b'), (5,'c'), (NULL,'d');只是指定了部分id的值。另一种类型的“混合模式插入”是INSERT ... ON DUPLICATE KEY UPDATE。
一个事务在持有AUTO-INC锁的过程中，其他事务的插入语句都要被阻塞，可以保证一个语句中分配的递增值是连续的。因此，其并发性并不高，当向一个有AUTO_INCREMENT关键字的主键插入值时，每条语句都要对这个表锁进行竞争，这样的并发潜力是很低下的，所以innodb通过 innodb_autoinc_lock_mode 的不同取值来提供不同的锁定机制，来提高SQL语句的可伸缩性和性能。
（1）innodb_autoinc_lock_mode = 0(“传统”锁定模式)
每当执行insert的时候，都会得到一个表级锁(AUTO-INC锁)，使得语句中生成的auto_increment为顺序，且在bin log中重放的时候，可以保证master与slave中数据的auto_increment是相同的。因为是表级锁，当在同一时间多个事务中执行insert的时候，对于AUTO-INC锁的争夺会 限制并发 能力。
（2）innodb_autoinc_lock_mode = 1(“连续”锁定模式)
在 MySQL 8.0 之前，连续锁定模式是 默认 的。
在这个模式下，“bulk inserts”仍然使用AUTO-INC表级锁，并保持到语句结束。同一时刻只有一个语句可以持有AUTO-INC锁。对于“Simple inserts”（要插入的行数事先已知），则通过在 mutex（轻量锁） 的控制下获得所需数量的自动递增值来避免表级AUTO-INC锁， 它只在分配过程的持续时间内保持，而不是直到语句完成。不使用表级AUTO-INC锁，除非AUTO-INC锁由另一个事务保持。如果另一个事务保持AUTO-INC锁，则“Simple inserts”等待AUTO-INC锁，如同它是一个“bulk inserts”。
（3）innodb_autoinc_lock_mode = 2(“交错”锁定模式)
从 MySQL 8.0 开始，交错锁模式是 默认 设置。
在这种锁定模式下，所有类似INSERT语句都不会使用表级AUTO-INC 锁，并且可以同时执行多个语句。这是最快和最可扩展的锁定模式，但是当使用基于语句的复制或恢复方案时，从二进制日志重播SQL语句时，这是不安全的。
在此锁定模式下，自动递增值 保证 在所有并发执行的所有类型的insert语句中是 唯一 且 单调递增 的。但是，由于多个语句可以同时生成数字（即，跨语句交叉编号），为任何给定语句插入的行生成的值可能不是连续的。
（4）元数据锁（MDL锁）
当对一个表做增删改查操作的时候，加 MDL 读锁；当要对表做结构变更操作的时候，加 MDL 写锁。不需要显示使用 ，在访问一个表的时候会被自动加上。
# 可用于查看锁表情况
show processlist;
2. InnoDB中的行锁
行锁 (Row Lock) 也称为记录锁，就是锁住某一行 (某条记录 row) 。需要的注意的是，MySQL 服务器层并没有实现行锁机制，行级锁只在存储引擎层实现
- 优点：锁定力度小，发生
锁冲突概率低，可以实现的并发度高 - 缺点：对于
锁的开销比较大，加锁会比较慢，容易出现死锁情况
lnnoDB与MyISAM的最大不同有两点: 一是支持事务；二是采用了行级锁。
（1）记录锁（Record Locks）
记录锁也就是仅仅把一条记录锁上，官方的类型名称为： LOCK_REC_NOT_GAP 。比如我们把id值为8的那条记录加一个记录锁的示意图如图所示。仅仅是锁住了id值为8的记录，对周围的数据没有影响。记录锁是有S锁和X锁之分的，称之为 S型记录锁 和 X型记录锁。
（2）间隙锁（Gap Locks）
MySQL 在 REPEATABLE READ 隔离级别下是可以解决幻读问题的，解决方案有两种：可以使用 MVCC 方案解决，也可以采用 加锁 方案解决。但是在使用加锁方案解决时有个大问题，就是事务在第一次执行读取操作时，那些幻影记录尚不存在，我们无法给这些 幻影记录 加上 记录锁 。InnoDB提出了一种称之为
Gap Locks 的锁，官方的类型名称为： LOCK_GAP ，我们可以简称为 gap锁 。比如，把id值为8的那条记录加一个gap锁的示意图如下。
begin;
select * from student where id = 5 for update;
图中id值为8的记录加了gap锁，意味着 不允许别的事务在id值为8的记录前边的间隙插入新记录 ，其实就是id列的值(3, 8)这个区间的新记录是不允许立即插入的。比如，有另外一个事务再想插入一条id值为4的新记录，它定位到该条新记录的下一条记录的id值为8，而这条记录上又有一个gap锁，所以就会阻塞插入操作，直到拥有这个gap锁的事务提交了之后，id列的值在区间(3, 8)中的新记录才可以被插入。如果插入值大于最大值20，则会锁大于20的所有id（用到了行格式中的最大记录）。
gap锁的提出仅仅是为了防止插入幻影记录而提出的。
该锁可能会产生死锁问题，如两个事务同时对区间(3, 8)加间隙锁，然后同时插入(3, 8)之间的数据，则会产生死锁，MySQL会检测到这个死锁并处理，默认会主动回滚死锁链条中的一个事务（3.6 中描述了死锁的解决方案）。
（3）临键锁（Next-Key Locks）
有时候我们既想 锁住某条记录 ，又想 阻止 其他事务在该记录前边的 间隙插入新记录 ，所以InnoDB就提出了一种称之为 Next-Key Locks 的锁，官方的类型名称为： LOCK_ORDINARY ，我们也可以简称为 next-key锁 。Next-Key Locks是在存储引擎 innodb 、事务级别在 可重复读 的情况下使用的数据库锁，innodb默认的锁就是Next-Key locks。
begin;
select * from student where id <=8 and id > 3 for update;
next-key锁 的本质就是一个 记录锁 和一个 间隙锁 的合体。它既能保护该条记录，又能阻止别的事务将新记录插入被保护记录前边的间隙。
（4）插入意向锁（Insert Intention Locks）
我们说一个事务在 插入 一条记录时需要判断一下插入位置是不是被别的事务加了 gap锁 （ next-key锁也包含 gap锁 ），如果有的话，插入操作需要等待，直到拥有 gap锁 的那个事务提交。但是InnoDB规定事务在等待的时候也需要在内存中生成一个锁结构，表明有事务想在某个 间隙 中 插入 新记录，但是现在在等待。InnoDB就把这种类型的锁命名为 Insert Intention Locks ，官方的类型名称为：LOCK_INSERT_INTENTION ，我们称为 插入意向锁 。插入意向锁是一种 Gap锁 ，不是意向锁，在insert操作时产生。当两个事务插入相同值时，只有一个会成功，当成功的事务提交后，另一个事务则会报主键重复异常。
插入意向锁并不会阻止别的事务继续获取该记录上任何类型的锁，多个事务插入相同值时可理解为一起加入等待集合中，但是最终只会有一个事务能执行成功。
3. 页锁
页锁就是在 页的粒度 上进行锁定，锁定的数据资源比行锁要多，因为一个页中可以有多个行记录，主要应用于内存数据库当中。当我们使用页锁的时候，会出现数据浪费的现象，但这样的浪费最多也就是一个页上的数据行。页锁的开销介于表锁和行锁之间，会出现死锁。锁定粒度介于表锁和行锁之间，并发度一般。主要应用于 BDB(BerkeleyDB) 存储引擎，置于内存中的表。
每个层级的锁数量是有限制的，因为锁会占用内存空间， 锁空间的大小是有限的 。当某个层级的锁数量超过了这个层级的阈值时，就会进行 锁升级 。锁升级就是用更大粒度的锁替代多个更小粒度的锁，比如InnoDB 中行锁升级为表锁，这样做的好处是占用的锁空间降低了，但同时数据的并发度也下降了。
3.3 从对待锁的态度划分:乐观锁、悲观锁
从对待锁的态度来看锁的话，可以将锁分成乐观锁和悲观锁，从名字中也可以看出这两种锁是两种看待 数据并发的思维方式 。需要注意的是，乐观锁和悲观锁并不是锁，而是锁的 设计思想 。
1. 悲观锁（Pessimistic Locking）
共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程。比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁，当
其他线程想要访问数据时，都需要阻塞挂起。
select ... where id = 1 for update;是MySQL中的悲观锁，如果在其他事务中执行 select ... where id = 1; 语句并不受影响，还可查出数据。
注意：select … for update语句执行过程中所有扫描的行都会被锁上，因此在MySQL中用悲观锁必须确定使用了索引，而不是全表扫描，否则将会把整个表锁住
悲观锁不适用的场景较多，它存在一些不足，因为悲观锁大多数情况下依靠数据库的锁机制来实现，以保证程序的并发访问性，同时这样对数据库性能开销影响也很大，特别是 长事务 而言，这样的 开销往往无法承受，这时就需要乐观锁。
2. 乐观锁（Optimistic Locking）
乐观锁认为对同一数据的并发操作不会总发生，属于小概率事件，不用每次都对数据上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，也就是不采用数据库自身的锁机制，而是通过程序来实现。在程序上，我们可以采用 版本号机制 或者 CAS机制 实现。
- 乐观锁的版本号机制
在表中设计一个 版本字段 version ，第一次读的时候，会获取 version 字段的取值。然后对数据进行更新或删除操作时，会执行 UPDATE ... SET version=version+1 WHERE version=version 。此时如果已经有事务对这条数据进行了更改，修改就不会成功
- 乐观锁的时间戳机制
时间戳和版本号机制一样，也是在更新提交的时候，将当前数据的时间戳和更新之前取得的时间戳进行比较，如果两者一致则更新成功，否则就是版本冲突。
3. 两种锁的适用场景
乐观锁适合读操作多的场景，相对来说写的操作比较少。它的优点在于程序实现，不存在死锁问题，不过适用场景也会相对乐观，因为它阻止不了除了程序以外的数据库操作悲观锁适合写操作多的场景，因为写的操作具有排它性。它可以在数据库层面阻止其他事务对该数据的操作权限，防止读 - 写和写 - 写的冲突
3.4 按加锁的方式划分：显式锁、隐式锁
1. 隐式锁
隐式锁主要用在插入场景中，在上文 写操作 中，新插入一条记录的操作并不加锁，通过一种称之为 隐式锁 的结构来保护这条新插入的记录在本事务提交前不被别的事务访问；还有插入意向锁，也是隐式锁。
- 情景一：对于聚簇索引记录来说，有一个
trx_id隐藏列，该隐藏列记录着最后改动该记录的事务id。那么如果在当前事务中新插入一条聚簇索引记录后，该记录的trx_id隐藏列代表的的就是当前事务的事务id，如果其他事务此时想对该记录添加 S锁 或者 X锁 时，首先会看一下该记录的trx_id隐藏列代表的事务是否是当前的活跃事务，如果是的话，那么就帮助当前事务创建一个 X 锁 （也就是为当前事务创建一个锁结构， is_waiting 属性是 false ），然后自己进入等待状态（也就是为自己也创建一个锁结构， is_waiting 属性是 true ）。 - 情景二：对于二级索引记录来说，本身并没有
trx_id隐藏列，但是在二级索引页面的Page Header部分有一个PAGE_MAX_TRX_ID属性，该属性代表对该页面做改动的最大的事务id，如果PAGE_MAX_TRX_ID属性值小于当前最小的活跃事务id，那么说明对该页面做修改的事务都已经提交了，否则就需要在页面中定位到对应的二级索引记录，然后回表找到它对应的聚簇索引记录，然后再重复情景一的做法
即:一个事务对新插入的记录可以不显式的加锁(生成一个锁结构)，但是由于 事务id 的存在，相当于加了一个隐式锁。别的事务在对这条记录加 S锁 或者 X锁 时，由于 隐式锁 的存在，会先帮助当前事务生成一个锁结构然后自己再生成一个锁结构后进入等待状态。隐式锁是一种 延迟加锁 的机制，从而来减少加锁的数量。
隐式锁的逻辑过程如下：
- InnoDB的每条记录中都一个隐含的trx_id字段，这个字段存在于聚簇索引的B+Tree中。
- 在操作一条记录前，首先根据记录中的trx_id检查该事务是否是活动的事务(未提交或回滚)。如果是活动的事务，首先将
隐式锁转换为显式锁(就是为该事务添加一个锁)。 - 检查是否有锁冲突，如果有冲突，创建锁，并设置为waiting状态。如果没有冲突不加锁，跳到5
- 等待加锁成功，被唤醒，或者超时
- 写数据，并将自己的trx_id写入trx_id字段
2. 显式锁
通过特定的语句进行加锁，我们一般称之为显示加锁，例如：
# 显式加共享锁
select .... lock in share mode;
# 显示加排它锁
select .... for update;
3.5 其它锁之：全局锁
全局锁就是对 整个数据库实例 加锁。当需要让整个库处于 只读状态 的时候，可以使用这个命令，之后其他线程的以下语句会被阻塞：数据更新语句（数据的增删改）、数据定义语句（包括建表、修改表结构等）和更新类事务的提交语句。全局锁的典型使用 场景 是：做 全库逻辑备份 。命令是：
# 加全局锁
Flush tables with read lock;
# 解锁
unlock tables;
3.6 其它锁之：死锁
死锁是指两个或多个事务在同一资源上相互占用，并请求锁定对方占用的资源，从而导致恶性循环。
当出现死锁以后，有 两种策略 ：
- 进入等待，直到超时。这个超时时间可以通过参数
innodb_lock_wait_timeout来设置，默认50秒- 缺点：对于在线服务来说，这个等待时长太长了，如果修改短又容易误伤到普通的锁等待
- 另一种策略是，发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务（将持有最少行级排他锁的事务进行回滚），让其他事务得以继续执行。将参数
innodb_deadlock_detect设置为 on ，默认开启
innodb提供了 wait-for graph 算法来主动进行锁检测，每当加锁请求无法立即满足需要并进入等待时，wait-for graph算法都会被触发。这是一种较为 主动的死锁检测机制 ，要求数据库保存 锁的信息链表 和 事务等待链表 两部分信息。基于这两个信息，可以绘制 wait-for graph (等待图，有向图)
死锁检测的原理是构建一个以事务为顶点、锁为边的有向图，判断有向图是否存在环，存在即有死锁
一旦检测到回路、有死锁，这时候lnnoDB存储引擎会选择回滚 undo量最小的事务，让其他事务继续执行( innodb_deadlock_detect=on 表示开启这个逻辑)。
缺点：每个新的被阻塞的线程，都要判断是不是由于自己的加入导致了死锁，这个操作时间复杂度是O(n ^ 2)。如果100个并发线程同时更新同一行，意味着要检测100 *100 = 1万次，1万个线程就会有1千万次检测。
如何解决?
- 方式1: 关闭死锁检测，但意味着可能会出现大量的超时，会导致业务有损。
- 方式2：控制并发访问的数量。比如在中间件中实现对于相同行的更新，在进入引擎之前排队，这样在InnoDB内部就不会有大量的死锁检测工作。
进一步的思路:
可以考虑通过将一行改成逻辑上的多行来减少 锁冲突。比如，连锁超市账户总额的记录，可以考虑放到多条记录上。账户总额等于这多个记录的值的总和。
4. 锁监控
关于MySQL锁的监控，我们一般可以通过检查 InnoDB_row_lock 等状态变量来分析系统上的行锁的争夺情况
show status like 'innodb_row_lock%';
Innodb_row_lock_current_waits：当前正在等待锁定的数量Innodb_row_lock_time：从系统启动到现在锁定总时间长度；（等待总时长）Innodb_row_lock_time_avg：每次等待所花平均时间；（等待平均时长）Innodb_row_lock_time_max：从系统启动到现在等待最常的一次所花的时间；Innodb_row_lock_waits：系统启动后到现在总共等待的次数；（等待总次数）
其他监控方法：
MySQL把事务和锁的信息记录在了 information_schema 库中，涉及到的三张表分别是 INNODB_TRX 、 INNODB_LOCKS 和 INNODB_LOCK_WAITS 。
MySQL5.7及之前 ，可以通过 information_schema.INNODB_LOCKS 查看事务的锁情况，但只能看到阻塞事务的锁；如果事务并未被阻塞，则在该表中看不到该事务的锁情况。
MySQL8.0删除了 information_schema.INNODB_LOCKS，添加了 performance_schema.data_locks ，可以通过该表查看事务的锁情况，和MySQL5.7及之前不同，该表不但可以看到阻塞该事务的锁，还可以看到该事务所持有的锁。
同时，information_schema.INNODB_LOCK_WAITS 也被 performance_schema.data_lock_waits 所代替
5. 附录
间隙锁是在可重复读隔离级别下才会生效的： next-key lock（临键锁） 实际上是由间隙锁加行锁实现的，如果切换到读提交隔离级别 (read-committed) 的话，就好理解了，过程中去掉间隙锁的部分，也就是只剩下行锁的部分。而在读提交隔离级别下间隙锁就没有了，为了解决可能出现的数据和日志不一致问题，需要把
bin log 格式设置为 row 。也就是说，许多公司的配置为：读提交隔离级别加 binlog_format=row。业务不需要可重复读的保证，这样考虑到读提交下操作数据的锁范围更小（没有间隙锁），这个选择是合理的。
next-key lock的加锁规则：
总结的加锁规则里面，包含了两个原则、两个优化和一个bug。
- 原则 1 ：加锁的基本单位是 next-key lock 。 next-key lock 是前开后闭区间。
- 原则 2 ：查找过程中访问到的对象才会加锁。任何辅助索引上的锁，或者非索引列上的锁，最终都要回溯到主键上，在主键上也要加一把锁。
- 优化 1 ：索引上的等值查询，给唯一索引加锁的时候， next-key lock 退化为行锁。也就是说如果InnoDB扫描的是一个主键、或是一个唯一索引的话，那InnoDB只会采用行锁方式来加锁
- 优化 2 ：索引上（不一定是唯一索引）的等值查询，向右遍历时且最后一个值不满足等值条件的时候， next-keylock 退化为间隙锁
- 一个 bug ：唯一索引上的范围查询会访问到不满足条件的第一个值为止。
418
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
