MySQL解决并发事务带来的问题--锁--锁的内存结构

上篇：MySQL解决并发事务带来的问题–锁

InnoDB锁的内存结构

对一条记录加锁的本质就是在内存中创建一个锁结构与之关联，那么是不是一个事务对多条记录加锁，就要创建多个锁结构呢？如果一个事务要获取10000条记录的锁，就要生成10000个这样的结构，开销就太大了。

InnoDB在对不同记录加锁时，如果符合下边这些条件，那么这些记录的锁就可以被放到一个锁结构中：

• 在同一个事务中进行加锁操作

• 被加锁的记录在同一个页面中

• 加锁的类型是一样的

• 等待状态是一样的
  

• 锁所在的事务信息：哪个事务生成了这个锁结构，就记载这个事务的信息。

• 索引信息：对于行锁来说，需要记录一下加锁的记录是属于哪个索引的。

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

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

  1. 锁的模式（ lock_mode ），占用低4位。
  2. 锁的类型（ lock_type ），占用第5～8位，不过现阶段只有第5位和第6位被使用
     
  3. 行锁的具体类型（ rec_lock_type ），使用其余的位来表示。只有在 lock_type 的值为 LOCK_REC时，也就是只有在该锁为行级锁时，才会被细分为更多的类型。

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

• 比特位：如果是行锁结构的话，在该结构末尾还放置了一堆比特位。页面中的每条记录在记录头信息中都包含一个heap_no属性，伪记录Infimum的heap_no值为0，Supremum的heap_no值为1，之后每插入一条记录，heap_no值就增1。锁结构最后的一堆比特位就对应着一个页面中的记录，一个比特位映射一个heap_no。