一、创建锁结构规则

当对一条记录加锁的本质就是在内存中创建一个锁结构与之关联，那么是不是一个事务对多条记录加锁，就要创建多个锁结构？理论上创建多个锁结构没问题，但是如果一个事务要获取1万条记录的锁，生成1万个锁结构也太崩溃了，所以决定在对不同记录加锁时，如果符合下边这些条件的记录会放到一个锁结构中
1、在同一个事务中进行加锁操作
2、被加锁的记录在同一个页面中
3、加锁的类型是一样的
4、等待状态是一样的

二、锁的内存结构

InnoDB 存储引擎中的 锁结构.png

1、结构解析

1、锁所在的事务信息

不论是 表锁 还是 行锁 ，都是在事务执行过程中生成的，哪个事务生成了这个 锁结构 ，这里就记录这个事务的信息。
此 锁所在的事务信息 在内存结构中只是一个指针，通过指针可以找到内存中关于该事务的更多信息，比方说事务id等

2、索引信息

对于 行锁 来说，需要记录一下加锁的记录是属于哪个索引的。这里也是一个指针。

3、 表锁／行锁信息

表锁结构 和 行锁结构 在这个位置的内容是不同的

3.1、表锁

记载着是对哪个表加的锁，还有其他的一些信息

3.2、行锁

• Space ID ：记录所在表空间

• Page Number ：记录所在页号

• n_bits ：对于行锁来说，一条记录就对应着一个比特位，一个页面中包含很多记录，用不同的比特位来区分到底是哪一条记录加了锁。为此在行锁结构的末尾放置了一堆比特位，这个n_bits 属性代表使用了多少比特位。

• n_bits的值一般都比页面中记录条数多一些。主要是为了之后在页面中插入了新记录后也不至于重新分配锁结构

4、 type_mode

这是一个32位的数，被分成了 lock_mode 、 lock_type 和 rec_lock_type 三个部分

type_mode的各个二进制为的作用.png

4.1、锁的模式（ lock_mode ），占用低4位，可选的值如下

在InnoDB存储引擎中，LOCK_IS，LOCK_IX，LOCK_AUTO_INC都算是表级锁的模式，LOCK_S和 LOCK_X既可以算是表级锁的模式，也可以是行级锁的模式

• LOCK_IS （十进制的 0 ）：表示共享意向锁，也就是 IS锁 。
• LOCK_IX （十进制的 1 ）：表示独占意向锁，也就是 IX锁 。
• LOCK_S （十进制的 2 ）：表示共享锁，也就是 S锁 。
• LOCK_X （十进制的 3 ）：表示独占锁，也就是 X锁 。
• LOCK_AUTO_INC （十进制的 4 ）：表示 AUTO-INC锁 。

4.2、锁的类型（ lock_type ），占用第5～8位，不过现阶段只有第5位和第6位被使用

• LOCK_TABLE （十进制的 16 ），也就是当第5个比特位置为1时，表示表级锁。
• LOCK_REC （十进制的 32 ），也就是当第6个比特位置为1时，表示行级锁。

4.3、行锁的具体类型（ rec_lock_type ），使用其余的位来表示。只有在 lock_type 的值为LOCK_REC 时，也就是只有在该锁为行级锁时，才会被细分为更多的类型

• LOCK_ORDINARY（十进制的 0 ）：表示 next-key锁 。

• LOCK_GAP （十进制的 512 ）：也就是当第10个比特位置为1时，表示 gap锁 。

• LOCK_REC_NOT_GAP （十进制的 1024 ）：也就是当第11个比特位置为1时，表示正经 记录 锁。

• LOCK_INSERT_INTENTION （十进制的 2048 ）：也就是当第12个比特位置为1时，表示插入意向锁。其他的类型：还有一些不常用的类型

• is_waiting 属性呢？基于内存空间的节省，所以把 is_waiting 属性放到了 type_mode 这个32位的数字中

  • LOCK_WAIT （十进制的 256 ） ：当第9个比特位置为 1 时，表示 is_waiting 为 true ，也就是当前事务尚未获取到锁，处在等待状态；当这个比特位为 0 时，表示 is_waiting 为 false ，也就是当前事务获取锁成功。

5、其他信息

为了更好的管理系统运行过程中生成的各种锁结构而设计了各种哈希表和链表

6、一堆比特位

如果是 行锁结构 的话，在该结构末尾还放置了一堆比特位，比特位的数量是由上边提到的 n_bits 属性表示的。InnoDB数据页中的每条记录在 记录头信息 中都包含一个 heap_no 属性，伪记录 Infimum 的 heap_no 值为 0 ， Supremum 的 heap_no 值为 1 ，之后每插入一条记录， heap_no 值就增1。 锁结构 最后的一堆比特位就对应着一个页面中的记录，一个比特位映射一个 heap_no ，即一个比特位映射到页内的一条记录。

三、锁监控

3.1、通过 InnoDB_row_lock 来监控

SHOW STATUS LIKE 'innodb_row_lock%';

image.png

• Innodb_row_lock_current_waits：当前正在等待锁定的数量
• Innodb_row_lock_time ：从系统启动到现在锁定总时间长度；（等待总时长）
• Innodb_row_lock_time_avg ：每次等待所花平均时间；（等待平均时长）
• Innodb_row_lock_time_max：从系统启动到现在等待最常的一次所花的时间；
• Innodb_row_lock_waits ：系统启动后到现在总共等待的次数；（等待总次数）

3.2、其他监控方法

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 ，可以通过performance_schema.data_locks查看事务的锁情况，和MySQL5.7及之前不同，performance_schema.data_locks不但可以看到阻塞该事务的锁，还可以看到该事务所持有的锁。同时，information_schema.INNODB_LOCK_WAITS也被 performance_schema.data_lock_waits 所代替。

• 查询正在被锁阻塞的sql语句

SELECT * FROM information_schema.INNODB_TRX;

• 查询锁等待情况

SELECT * FROM data_lock_waits;

• 查询锁的情况

 SELECT * from performance_schema.data_locks;