lock_rec_t的关键字段包括space_id、page_no、n_bits及末尾动态分配的比特位数组，用于页内记录映射；间隙信息由type_mode第10位标识，不单独存偏移。

行级锁的内存载体是 lock_t 结构体

MySQL InnoDB 的行级锁不是散落在各处的标记，而是统一由一个名为 lock_t 的 C 结构体实例表示。它不是抽象概念，而是真实分配在 Buffer Pool 附近内存区域中的对象，由锁管理器（lock_sys）通过哈希表索引和链表组织。

这个结构体里最关键的字段包括：trx（指向持有锁的事务）、index（指向被加锁记录所属的索引）、type_mode（编码了锁类型、模式、等待状态等信息），以及一个 union：里面实际存放的是 lock_rec_t（行锁专用子结构）或 lock_table_t（表锁专用子结构）。行级锁真正起作用的数据都在 lock_rec_t 里。

lock_rec_t 里存着哪些关键字段？

当你执行 SELECT ... FOR UPDATE 或 UPDATE 触发行锁时，InnoDB 会填充 lock_rec_t 中的几个核心字段：

• space_id 和 page_no：定位到具体哪个表空间、哪一页——因为行锁本质是“页内比特位映射”，不是按行地址硬绑定
• n_bits：表示该页内最多有多少条记录可能被锁，用于分配末尾那块比特数组（bitmask）；注意它不等于当前已锁行数，而是页内用户记录总数 + 1（含 supremum）
• 末尾紧跟着一块动态分配的比特位数组：每一位对应页内一条用户记录（包括 infimum/supremum），置 1 表示该记录被当前锁结构覆盖
• 间隙信息（如 LOCK_GAP）不单独存偏移，而是通过 type_mode 的第 10 位标识，并结合记录本身的 key 值推导出锁定区间

为什么同一个锁结构能管住多行？

不是每行都新建一个 lock_t，否则万行更新就上万个锁对象，内存和哈希查找开销爆炸。InnoDB 会合并满足全部以下条件的加锁请求：

• 属于同一个事务（trx 指针相同）
• 目标记录落在同一个数据页（space_id + page_no 相同）
• 锁模式完全一致（比如都是 LOCK_X | LOCK_REC_NOT_GAP）
• 等待状态一致（要么都已获得，要么都处于 LOCK_WAIT）

满足这四点，就复用同一个 lock_t，只扩展其末尾的比特位数组——这是行锁高效的关键设计，但也是排查死锁时容易误判“单行锁”实为“页级批量锁”的根源。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

查不到 lock_t 地址？别直接看内存，用 performance_schema.data_locks

你没法在生产环境用 gdb 抓取 lock_t* 地址并 dump，也不该这么干。MySQL 提供了安全、标准化的观测入口：performance_schema.data_locks 表。

它把 lock_t 中的关键语义字段做了投影：

• lock_type → 映射自 type_mode 第 5–6 位（LOCK_REC 或 LOCK_TABLE）
• lock_mode → 解析低 4 位（LOCK_S / LOCK_X / LOCK_GAP 等组合）
• lock_data → 不是内存地址，而是该锁覆盖的索引值（如 20）或区间（如 20, 30），对间隙锁会显示空或 NULL
• index_name + object_name → 回溯到 index 和 dict_table_t 的可读名

真正难的是理解 lock_data 为空时到底锁了什么——那往往意味着间隙锁或临键锁覆盖了“不存在的值”，得结合执行计划和索引 B+ 树结构反推。