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 会合并满足全部以下条件的加锁请求：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 属于同一个事务（
trx指针相同） - 目标记录落在同一个数据页（
space_id+page_no相同） - 锁模式完全一致（比如都是
LOCK_X | LOCK_REC_NOT_GAP） - 等待状态一致（要么都已获得，要么都处于
LOCK_WAIT）
满足这四点，就复用同一个 lock_t，只扩展其末尾的比特位数组——这是行锁高效的关键设计，但也是排查死锁时容易误判“单行锁”实为“页级批量锁”的根源。
查不到 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+ 树结构反推。
