mysql 8.0行锁管理并不更节省内存，单个锁对象反而大16–24字节；真正改善的是高并发下锁系统争用开销和内存峰值压力，源于lock_sys分片哈希+位图快照、毫秒级死锁检测及间隙锁行为收敛。
MySQL 8.0 的行锁管理并不比 5.7 更节省内存——单个锁对象实际更大，所谓“更优”是误读；真正改善的是高并发下锁系统整体内存压力与争用开销，根源在于结构重构而非压缩。
为什么 innodb_row_lock_waits 计数变慢，不等于锁更轻？
很多人看到升级后 innodb_row_lock_waits 增长放缓，就以为锁占内存少了。其实这是锁等待被更快识别并回滚的结果：
- 5.7 中事务可能排队等满
innodb_lock_wait_timeout（默认 50 秒）才触发死锁检测，期间持续 hold 锁对象，锁链拉长、内存累积 - 8.0 默认开启
innodb_deadlock_detect=ON，后台线程持续维护 wait-for graph，死锁在毫秒级被发现并回滚，锁对象存活时间大幅缩短 - 锁对象本身没变小，但“堆积滞留”减少，间接降低锁系统内存峰值压力
lock_sys->rec_hash 分片 + 位图如何影响内存分布？
8.0 把原来全局单 mutex 的 lock_sys 拆成哈希分片（rec_hash 和 prdt_hash），每个分片配独立 mutex，并用位图标记页内锁状态：
- 位图不是逐行记录，而是按
page_no + heap_no编码，在 page 粒度做“有无锁”快照，再挂哈希链存具体锁信息 - 相同 UPDATE 影响 100 行：5.7 可能建 3–4 个传统锁对象；8.0 常合并为 1 个位图锁（覆盖整页范围）
- 但每个位图锁对象比传统锁大 16–24 字节（含 bitmap header 和动态位数组指针）
- 若
performance_schema.data_locks中某 hash bucket 记录数 > 200，说明分片不均，需调大innodb_sync_array_size（默认 16）
间隙锁数量变多，是 bug 还是更真实？
执行 SELECT ... FOR UPDATE 覆盖非唯一索引范围时，8.0 在 performance_schema.data_locks 中显示的 gap 锁数量常比 5.7 多——这不是膨胀，而是行为收敛：
- 5.7 的间隙锁常因优化器估算偏差而“模糊合并”，表面锁少，实则漏锁或范围不准
- 8.0 用区间树（interval tree）精确管理 gap 范围，并将 gap 锁与
LOCK_INSERT_INTENTION分离存储 - 结果是锁数量上升、监控更透明，但加锁逻辑更稳定，避免了某些隐性死锁或幻读
- 内存表现“更诚实”：你看到的锁数量，基本就是它真正在管的范围
真正容易被忽略的点是：锁内存优化只在锁竞争密集场景（如热点行高频更新）才有感知；若业务以读为主或写冲突低，8.0 的锁结构反而因位图头开销略增内存占用。 是否调优 innodb_sync_array_size 或启用位图锁，必须结合 performance_schema.data_locks 实际分布判断，不能一概而论。
