Analysis of InnoDB Table and Row Lock Structures in MySQL 8.0.32

Based on MySQL 8.0.32 source code (InnoDB storage engine), this article explains the common and different attributes of table‑lock and row‑lock structures.

Both lock types use the lock_t structure, which contains a union of lock_table_t (table lock) and lock_rec_t (row lock). After removing non‑core fields, the simplified definition is:

struct lock_t {
  trx_t *trx;
  UT_LIST_NODE_T(lock_t) trx_locks;
  dict_index_t *index;
  lock_t *hash;
  union {
    lock_table_t tab_lock;
    lock_rec_t rec_lock;
  };
  uint32_t type_mode;
};

The type_mode field occupies 4 bytes (32 bits) and is divided into four parts:

Bits 1‑4: lock mode (e.g., LOCK_IS, LOCK_IX, LOCK_S, LOCK_X, LOCK_AUTO_INC).

Bits 5‑8: lock type flags (LOCK_TABLE, LOCK_REC, unused).

Bit 9: lock wait status (0 = granted, 1 = waiting).

Bits 10‑32: precise lock mode used only by row locks (gap lock, record lock, insert‑intention lock, predicate lock, etc.).

Table‑lock structures use only three fields from lock_t ( trx , trx_locks , type_mode ) plus the table and locks fields of lock_table_t . They are linked to other locks via the locks list, allowing InnoDB to traverse all locks on a table and decide compatibility.

Row‑lock structures contain five fields from lock_t ( trx , trx_locks , index , hash , type_mode ) plus page_id and n_bits from lock_rec_t . The hash field groups locks that belong to the same page, while n_bits indicates how many records can share the same lock structure.

To avoid memory waste, InnoDB merges multiple row‑lock structures that share the same attributes (same transaction, same page, same lock mode, same precise mode, and all granted) into a single structure and uses an unnamed bitmap area to record which records are locked. Each bit in the bitmap corresponds to a record; a set bit means the transaction holds a lock on that record.

The article lists the conditions required for row‑locks to be merged:

The same transaction locks multiple records.

All records reside on the same data page.

All locks have the same mode (shared or exclusive).

All locks have the same precise mode (record lock, gap lock, or Next‑Key lock).

All locks are granted (not waiting).

Two special cases cannot be merged: (1) row‑locks that are in waiting state, because a transaction cannot hold multiple waiting locks simultaneously; (2) insert‑intention locks, because they must coexist with gap locks that have different precise modes.

In summary, InnoDB defines three structs to describe lock information, table locks are created per table per transaction, row locks can be shared when the above conditions are met, waiting row locks cannot be shared, and insert‑intention locks are always separate.