关于YugabyteDB中乐观锁与悲观锁支持情况的技术问询

一、悲观锁与悲观并发控制的概念及YugabyteDB支持情况 #

• 悲观锁和悲观并发控制属于同一类概念：悲观并发控制是一种并发控制策略，核心是假设冲突会频繁发生，提前锁定资源避免后续操作冲突；悲观锁是该策略下的具体实现手段，二者逻辑完全一致。
• 文档表述矛盾的原因是版本演进：YugabyteDB早期仅支持乐观并发控制（OCC），随着版本迭代，部分悲观锁能力（如SELECT ... FOR UPDATE基础语法）已逐步落地，但完整的悲观并发控制体系（全场景行级锁阻塞、跨节点锁协调的完善支持）仍在开发中。文档顶部描述对应最新预览版的已实现/规划内容，而悲观并发控制章节的备注可能是未及时更新的旧内容，或是指完整框架尚未成熟。
• 当前最新稳定版YugabyteDB对悲观锁是部分支持：FOR UPDATE/FOR NO KEY UPDATE等语法可执行，但锁行为更偏向"乐观锁增强"——不会像单节点PostgreSQL那样直接阻塞等待，而是在事务提交阶段做冲突检查，冲突则触发重试。

二、select-then-update场景的无重试阻塞可行性及优化方案 #

你的场景是典型的抢占式任务分配，想要实现无需客户端重试的阻塞等待，目前YugabyteDB暂无法完全实现，原因在于：

1. 分布式架构下，锁的协调是异步的，无法像单节点数据库那样立即阻塞其他事务；
2. 核心事务引擎基于乐观并发控制设计，所有写操作最终都会在提交阶段做冲突校验，冲突则返回错误需客户端重试。

不过可以通过以下方式优化，大幅减少重试次数，接近预期效果：

• 改用SELECT ... FOR UPDATE SKIP LOCKED：跳过已被锁定的行，直接获取下一个可用行，避免等待，降低冲突概率；
• 将select和update合并为单条原子SQL：

  UPDATE entries 
  SET owner = '$1' 
  WHERE id = (
      SELECT id FROM entries WHERE owner IS NULL LIMIT 1
  )
  RETURNING id;
  

  单条SQL的原子性更强，YugabyteDB会自动处理内部锁逻辑，冲突概率远低于分开的select-then-update；
• 调整事务隔离级别为REPEATABLE READ：该级别下YugabyteDB提供更强的一致性保证，减少不可重复读导致的冲突。

需明确：YugabyteDB的分布式特性决定了它无法像单节点关系型数据库那样提供完全同步的阻塞式悲观锁，客户端侧的重试逻辑目前仍是高并发场景下的必要环节。

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