假如说 我们SELECT * FROM table WHERE a < 10000 FOR UPDATE 那岂不是要加几万条锁 这消耗老鼻子内存了 这些锁有很多地方都是一样的啊 能不能通过某种方式整理整理节省点内存呢?
答案是能
如果符合下边这些条件：
在同一个事务中进行加锁操作
被加锁的记录在同一个数据页中
加锁的类型是一样的
等待状态是一样的
那么这些记录的锁就可以被放到一个 锁结构 中
那么锁结构长啥样呢 呃呃 长这样(谁问我了?)
锁所在的事务信息:
哪个事务生成了这个 锁结构 ，这里就记载着这个事务的信息。(不是事务ID啊 是事务信息 那放的下吗? 它在内存结构中只是一个指针而已，所以不会占用多大内存空间，通过指针可以找到内存中关于该事务的更多信息，比方说事务id是什么。下边介绍的所谓的`索引信息`其实也是一个指针)
索引信息
对于 行锁 来说，需要记录一下加锁的记录是属于哪个索引的。
表锁/行锁信息
表锁：记载着这是对哪个表加的锁，还有其他的一些信息
行锁:
记载了三个重要的信息：
Space ID 记录所在表空间。
Page Number 记录所在页号。
n_bits:对于行锁来说，一条记录就对应着一个比特位，一个页面中包含很多记录，用不同的比特位来区分到底是哪一条记录加了锁。为此在行锁结构的末尾放置了一堆比特位，这个 n_bits 属性代表使用了多少比特位。并不是该页面中有多少记录，n_bits属性的值就是多少。为了让之后在页面中插入了新记录后也不至于重新分配锁结构，所以n_bits的值一般都比页面中记录条数多一些
怎么记忆呢 你看表锁里面记录的是哪个表 那么行锁肯定就要记录哪个行 那么这个行也就是一条记录 他需要怎么记录呢? 同一张表不一定在一个数据页中 所以这两个数据参数都要 再有呢 表是唯一的 但是行可以有很多行 我们统一记录相同数据页和相同表中的大量锁(也是可以放进同一个锁结构的条件)
type_mode
这是一个32位的数，被分成了 lock_mode 、 lock_type 和 rec_lock_type 三个部分，如图所示：
锁的模式（ lock_mode ）
占用低4位，
可选的值如下：
LOCK_IS （十进制的 0 ）0000：表示共享意向锁，也就是 IS锁 。
LOCK_IX （十进制的 1 ）0001：表示独占意向锁，也就是 IX锁 。
LOCK_S （十进制的 2 ）0010：表示共享锁，也就是 S锁 。
LOCK_X （十进制的 3 ）0011：表示独占锁，也就是 X锁 。
LOCK_AUTO_INC （十进制的 4 ）0100：表示 AUTO-INC锁
锁的类型（ 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时，表示插入意向锁。
其他的类型：还有一些不常用的类型我们就不多说了。
LOCK_WAIT （十进制的 256 ） ：也就是当第9个比特位置为 1 时，表示 is_waiting 为 true ，也就是当前事务尚未获取到锁，处在等待状态；当这个比特位为 0 时，表示 is_waiting 为 false ，也就是当前事务获取锁成功。
其他信息
为了更好的管理系统运行过程中生成的各种锁结构而设计了各种哈希表和链表，为了简化讨论，我们忽略这部分信息
如果是 行锁结构 的话，在该结构末尾还放置了一堆比特位，比特位的数量是由上边提到的 n_bits 属性表示的。我们前边唠叨InnoDB记录结构的时候说过，页面中的每条记录在 记录头信息 中都包含一个 heap_no 属性，伪记录 Infimum 的 heap_no 值为 0 ， Supremum 的 heap_no 值为 1 ，之后每插入一条记录， heap_no值就增1。 锁结构 最后的一堆比特位就对应着一个页面中的记录，一个比特位映射一个 heap_no ，不过为了编码方便，映射方式有点怪：
