Slow Locking Logic in MySQL InnoDB

1. Did we lock already?

The fast‑locking path handles only trivial cases; the slow‑locking logic is invoked when any slow‑lock condition is met. It first checks whether the current transaction T1 has already locked the target record R1 . If a matching lock exists with sufficient mode and precision, the lock acquisition ends early.

2. Need to wait?

If T1 does not already hold an adequate lock, the engine must determine whether other transactions’ locks will block it. It locates the hash bucket rec_hash for the data page containing R1 , then traverses the linked list of row‑lock structures, examining each hash lock entry.

For each hash entry the engine checks two conditions: (1) the page_id matches the page of R1 , and (2) the bitmap has the bit for R1 set. If both hold, further checks are performed:

Whether the lock is in a waiting state.

Whether the lock was created by T1 itself.

Compatibility of lock modes using the lock‑mode matrix ("+" means compatible, "-" means conflict).

Compatibility of precise lock types (e.g., LOCK_REC_NOT_GAP , LOCK_GAP , LOCK_ORDINARY , LOCK_INSERT_INTENTION ).

Special rules for insert‑intention locks, supremum records, and high‑priority transactions.

If any check determines that the hash lock will not block T1 , the algorithm proceeds; otherwise T1 enters the lock‑wait state.

3. Reuse an existing lock structure

The engine attempts to find a reusable row‑lock structure that belongs to T1 , has the same lock mode and precision as the requested lock, is not waiting, and whose bitmap already contains the bit for R1 . If such a structure is found, the bitmap bit is set to 1 and the lock acquisition finishes.

4. Allocate a new lock structure

If no reusable structure exists, a new row‑lock structure is allocated, its fields are initialized, and it is inserted at the head of the rec_hash bucket list and appended to the transaction’s trx_locks list. The bitmap for R1 is then set to 1.

5. Summary

Check whether T1 already holds a suitable lock on R1 . If so, skip further locking.

Determine if other transactions’ locks would block T1 ; if they do, T1 waits.

Try to reuse an existing compatible lock structure; if found, update its bitmap.

If reuse fails, allocate and initialize a new lock structure and link it into the appropriate hash bucket and transaction lock list.