PostgreSQL行级锁类型解析：各类锁的适用场景咨询

行级锁的选择核心是平衡数据一致性需求和并发性能——锁越严格，一致性保障越强，但并发冲突概率越高；锁越宽松，并发能力越好，需确保不破坏业务规则。以下是四种锁的具体特性、适用场景及选择逻辑：

1. FOR UPDATE #

• 锁行为：最严格的排他锁，会阻塞所有其他事务对该行加任何行级锁（包括FOR NO KEY UPDATE/FOR SHARE/FOR KEY SHARE），同时阻止任何修改、删除操作。事务提交或回滚后释放锁。
• 适用场景：
  • 修改行的主键/唯一约束字段时（比如更新用户唯一手机号、订单编号），防止其他事务同时修改导致唯一约束冲突。
  • 业务需完全锁定行的场景：比如电商支付流程中锁定订单行，避免重复支付；秒杀活动中锁定库存行，防止超卖。
  • 强一致性要求的悲观锁场景，确保后续操作（删除、全量更新）不受其他事务干扰。
• 实际影响：并发性能最低，易引发锁等待甚至死锁，非必要不滥用。

2. FOR NO KEY UPDATE #

• 锁行为：排他锁，但仅阻塞其他事务加FOR UPDATE或FOR NO KEY UPDATE，允许加FOR SHARE和FOR KEY SHARE——即其他事务可读取并加共享锁，但无法修改该行。
• 适用场景：
  • 修改行的非主键/非唯一约束字段时（比如更新用户昵称、商品描述、订单备注），无需阻止其他事务读取或加共享锁，可减少并发冲突。
  • 批量更新普通数据场景：比如批量调整用户积分，允许其他事务同时查询积分状态，提升并发能力。
• 实际影响：比FOR UPDATE宽松，并发性能更好，是日常修改非关键字段的首选。

3. FOR SHARE #

• 锁行为：共享锁，允许其他事务加FOR SHARE或FOR KEY SHARE，但会阻塞FOR UPDATE和FOR NO KEY UPDATE——即阻止任何修改、删除操作。
• 适用场景：
  • 读取数据时需确保该行不被任何事务修改/删除：比如财务系统读取用户账户余额，避免读取期间余额变更导致计算结果不一致。
  • 配合外键使用：比如读取订单数据时锁定关联的用户行，防止用户行被删除引发外键约束错误。
• 实际影响：保证读取数据一致性，允许多个事务同时加共享锁，并发性能优于排他锁，但会阻断所有修改操作。

4. FOR KEY SHARE #

• 锁行为：最宽松的共享锁，仅阻塞FOR UPDATE，与其他所有行级锁（FOR NO KEY UPDATE/FOR SHARE/FOR KEY SHARE）兼容——即其他事务可修改非主键/非唯一字段，也可加其他共享锁，仅修改主键/唯一字段的操作会被阻塞。
• 适用场景：
  • 仅需保护行的主键/唯一约束字段不被修改/删除，但允许修改其他字段：比如读取用户基本信息时，允许其他事务更新用户地址，但禁止修改用户ID或手机号。
  • 高并发读场景：比如电商商品列表页读取商品ID和名称，允许其他事务更新商品库存，但不能修改商品ID，最大化并发能力。
• 实际影响：并发性能最高，对业务限制最小，适合仅需保护关键键的读操作。

选择逻辑总结 #

1. 先判断操作类型：
   • 修改操作：
     • 改主键/唯一键 → 用FOR UPDATE
     • 改非主键/非唯一键 → 用FOR NO KEY UPDATE
   • 读操作：
     • 需完全阻止任何修改 → 用FOR SHARE
     • 仅需阻止修改主键/唯一键 → 用FOR KEY SHARE
2. 优先在满足一致性的前提下选更宽松的锁，提升并发性能。
3. 注意锁顺序：多个事务交叉加锁易引发死锁，需保证事务按相同顺序锁定行。

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