PostgreSQL SSI隔离级别下SELECT FOR UPDATE是否仍有使用意义

即使在PostgreSQL的可串行化快照隔离（SSI，即Serializable隔离级别）下，为先读后改的业务场景中的SELECT语句添加FOR UPDATE后缀依然具备明确的实际意义，并非冗余操作，核心原因和价值如下：

• 两者的冲突处理逻辑本质完全不同
  SSI防范写倾斜等异常的核心机制是事后冲突检测回滚：它会跟踪事务间的读写依赖关系，在事务提交阶段判定是否存在破坏串行化的冲突，一旦检测到冲突就会选择其中回滚代价最小的事务终止，抛出40001串行化失败错误，要求业务层重试。而SELECT ... FOR UPDATE是事前行级排他锁：执行查询时就会直接锁定匹配的目标行，其他试图修改、加锁这些行的并发事务会直接进入锁等待队列，不会并行执行到产生冲突的阶段，从根源上避免了冲突发生。
• 有效降低事务回滚开销，提升系统稳定性
  不加FOR UPDATE的纯SSI场景下，只要两个并发的读改事务触发了写倾斜类冲突，必然有一个已经执行了部分逻辑的事务会被强制回滚，回滚过程会浪费已消耗的计算、IO、连接资源，高并发场景下还可能出现回滚风暴。加了FOR UPDATE之后，冲突从“执行到提交阶段再回滚”变成“查询阶段排队等锁”，事务要么拿到锁顺利执行完所有逻辑，要么等锁时排队，不会出现执行中途被回滚的无效开销，系统吞吐表现会更稳定。
• 减少SSI假阳性回滚的影响
  SSI的串行化检测基于快照读的依赖跟踪，为了保证检测逻辑的性能，存在一定的假阳性概率：即某些实际不会破坏串行化一致性的并发事务，也可能被判定为冲突触发回滚。FOR UPDATE的行锁机制提前明确了行的修改权限，会让SSI的依赖判定更明确，大幅降低这类误判的出现概率。
• 兼容多隔离级别的逻辑一致性
  实际生产环境中很少有业务把所有事务都固定在Serializable隔离级别，比如批量数据修复、临时运维操作往往会使用默认的读提交（Read Committed）或可重复读（Repeatable Read）隔离级别。SQL语句中自带FOR UPDATE锁的话，就算事务隔离级别临时调整，也不会突然出现写倾斜的一致性问题，不需要为不同隔离级别维护两套独立的SQL逻辑。

注意：SSI和FOR UPDATE不是互斥的替代关系，而是兜底保障和事前规避的互补关系。SSI是整个隔离级别的全局一致性兜底，哪怕你写SQL时漏了加锁，它也能保证不会出现一致性异常；而FOR UPDATE是针对明确读改场景的优化，只要你确定查询出来的行后续要被更新，加FOR UPDATE在任何隔离级别下都不会有额外副作用，只会让逻辑执行更高效可靠。

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