锁的内部结构与锁监控

• InnoDB存储引擎中的锁结构
  

1. 锁所在的事务信息 ：
不论是 表锁 还是 行锁 ，都是在事务执行过程中生成的，哪个事务生成了这个 锁结构 ，这里就记录这个事务的信息
此 锁所在的事务信息 在内存结构中只是一个指针，通过指针可以找到内存中关于该事务的更多信息，比方说事务id等
 
2. 索引信息 ：
对于 行锁 来说，需要记录一下加锁的记录是属于哪个索引的。这里也是一个指针
 
3. 表锁／行锁信息 ：
表锁：记载着是对哪个表加的锁，还有其他的一些信息。
行锁：记载了三个重要的信息：
    Space ID ：记录所在表空间。
    Page Number ：记录所在页号。
    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 ，即一个比特位映射到页内的一条记录

• 锁监控

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

• 案例

# 开启1个新的连接，开启1个新的事务
begin;
# 查询的时候，获取排他锁
select * from user for update;
 
# 开启第2个新的连接，开启1个新的事务
begin;
# 查询的时候，获取排他锁，这是会处于阻塞状态
select * from user for update;
 
# 开启第3个新的连接，查看锁的状态
SELECT * from performance_schema.data_locks\G;