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