MVCC堆与二级B+树的锁机制优化问询

针对你当前实现中读被写阻塞的问题，核心是把B+树的结构保护逻辑和数据可见性判断逻辑彻底分离，不要用行级锁来控制数据可见性，而是依托MVCC的快照机制来处理。以下是具体优化方案：

1. 搜索操作：去掉S锁，用快照判断条目有效性 #

• 搜索全程不申请S锁，直接遍历B+树定位目标(key, RID)条目
• 拿到RID后，结合堆的MVCC历史列表和当前事务的快照做可见性判断：
  • 若条目未标记删除：直接用RID访问堆中符合事务快照的元组版本
  • 若条目已标记删除：通过条目扩展的delete_tx_id和commit_ts字段判断：
    • 若commit_ts ≤ 事务快照时间戳：删除已提交，该条目对当前事务不可见，返回“不存在”
    • 若commit_ts > 事务快照时间戳 或 删除未提交：条目仍有效，用RID访问堆中的历史元组（堆的MVCC已保留版本，不会失效）
• 补充：为避免读到半修改的B+树结构，给每个节点加版本戳，遍历前记录节点版本，遍历后校验，版本变化则重新遍历，这种乐观锁开销远低于行级S锁

2. 插入操作：X锁保护唯一性，快照判断冲突 #

• 找到目标叶子节点后，申请该节点的意向X锁（或仅针对插入键的X锁）
• 持有锁时，基于事务快照检查叶子节点内是否存在可见的同主键条目：
  • 若存在可见的同主键条目，抛出唯一性冲突
  • 若不存在，插入新的(key, RID)条目
• 插入完成后立即释放锁，堆中元组的版本由MVCC管理，不阻塞任何读操作

3. 删除操作：X锁仅保护条目标记，延迟物理删除 #

• 定位到目标(key, RID)条目后，申请该条目的X锁（或叶子节点的意向X锁）
• 持有锁时，给条目标记删除，并记录delete_tx_id（执行删除的事务ID）和commit_ts（提交时间戳）
• 释放锁，堆中的元组不会立即删除，等待后台清理线程在所有依赖该版本的事务结束后再回收
• 读操作通过快照判断删除是否可见，完全无需等待锁释放

解决“无锁读时无法判断删除条目提交状态”的问题 #

• 在B+树的(key, RID)条目中扩展两个字段：
  • delete_tx_id：执行删除操作的事务ID
  • commit_ts：删除操作的提交时间戳（未提交时设为最大值或特殊标记）
• 读操作拿到条目后，对比自己的事务快照时间戳：
  • 若删除已提交（commit_ts ≤ 快照时间戳）：条目不可见
  • 若删除未提交或不存在：条目有效，RID对应的堆元组历史版本依然存在，可正常访问

额外优化建议 #

• 延迟清理B+树已删除条目：不要立即物理删除标记的条目，等到节点分裂/合并时，或后台定时任务统一清理，清理前要确保所有事务的快照都晚于该条目的commit_ts，避免读操作找不到有效数据
• 意向锁替代行级锁：对叶子节点加意向锁而非单个键的锁，减少锁的粒度和开销，适合高并发场景

内容的提问来源于stack exchange，提问作者GenGG