MySQL solves the problems caused by concurrent transactions -- locks -- the memory structure of locks

Previous: MySQL solves the problem of concurrent transactions – locks

InnoDB lock memory structure

The essence of locking a record is to create a lock structure in memory to associate it with it. Is it necessary to create multiple lock structures when a transaction locks multiple records? If a transaction wants to acquire locks on 10,000 records, 10,000 such structures must be generated, which is too expensive.

When InnoDB locks different records, if the following conditions are met, the locks of these records can be placed in a lock structure:

• Locking in the same transaction

• Locked records are in the same page

• The type of lock is the same

• wait state is the same
  

• The transaction information where the lock is located: which transaction generates the lock structure, the information of the transaction is recorded.

• Index information: For row locks, it is necessary to record which index the locked record belongs to.

• Table lock/row lock information: The content of the table lock structure and the row lock structure in this position is different

• type_mode: This is a 32-bit number divided into three parts: lock_mode, lock_type and rec_lock_type.

  1. The mode of the lock ( lock_mode ), occupying the lower 4 bits.
  2. The type of lock ( lock_type ) occupies the 5th to 8th bits, but only the 5th and 6th bits are used at this stage
     
  3. The concrete type of row lock ( rec_lock_type ), represented by the remaining bits. Only when the value of lock_type is LOCK_REC, that is, only when the lock is a row-level lock, will it be subdivided into more types.

• Other information: Various hash tables and linked lists are designed to better manage various lock structures generated during the operation of the system.

• Bits: If it is a row lock structure, a bunch of bits are placed at the end of the structure. Each record in the page contains a heap_no attribute in the record header information. The heap_no value of the pseudo record Infimum is 0, and the heap_no value of Supremum is 1. After each record is inserted, the heap_no value is increased by 1. The last bunch of bits in the lock structure correspond to the records in a page, and each bit maps to a heap_no.