4. 锁的内存结构

InnoDB 存储引擎中的锁结构如下：

1. 锁所在的事务信息：

不论是表锁还是行锁，都是在事务执行过程中生成的，哪个事务生成了这个锁结构，这里就记录这个事务的信息。

此锁所在的事务信息在内存结构中只是一个指针，通过指针可以找到内存中关于该事务的更多信息，比方说事务id等。

2. 索引信息：

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

3. 表锁／行锁信息

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

表锁：

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

行锁：

记载了三个重要的信息：

• Space ID ：记录所在表空间。

• Page Number ：记录所在页号。

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

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

4. type_mode ：

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

• 锁的模式（ lock_mode ），占用低4位，可选的值如下：
  • LOCK_IS （十进制的0 ）：表示共享意向锁，也就是IS锁。
  • LOCK_IX （十进制的1 ）：表示独占意向锁，也就是IX锁。
  • LOCK_S （十进制的2 ）：表示共享锁，也就是S锁。
  • LOCK_X （十进制的3 ）：表示独占锁，也就是X锁。
  • LOCK_AUTO_INC （十进制的4 ）：表示AUTO-INC锁。

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

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

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

• 行锁的具体类型（ 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 ，即一个比特位映射到页内的一条记录。

5. 锁监控

关于MySQL锁的监控，我们一般可以通过检查InnoDB_row_lock 等状态变量来分析系统上的行锁的争夺情况

mysql> show status like 'innodb_row_lock%';
+-------------------------------+-------+
| Variable_name | Value |
+-------------------------------+-------+
| Innodb_row_lock_current_waits | 0 |
| Innodb_row_lock_time | 0 |
| Innodb_row_lock_time_avg | 0 |
| Innodb_row_lock_time_max | 0 |
| Innodb_row_lock_waits | 0 |
+-------------------------------+-------+
5 rows in set (0.01 sec)

对各个状态量的说明如下：

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

同时，information_schema.INNODB_LOCK_WAITS也被performance_schema.data_lock_waits 所代替。