游乐游手机版
首页/数据库/文章详情

PostgreSQL如何处理更新时的并发冲突_应用乐观锁逻辑与Version

时间:2026-04-26 20:41
PostgreSQL更新时出现“覆盖丢失”是因为其默认隔离级别不保证“读-改-写”原子性,需用version字段实现乐观锁:UPDATE带版本校验且检查ROW_COUNT是否为1。 PostgreSQL 更新时为什么会出现“覆盖丢失”? 想象这样一个场景:两个事务同时读取了同一行数据,各自在本地计算

PostgreSQL更新时出现“覆盖丢失”是因为其默认隔离级别不保证“读-改-写”原子性,需用version字段实现乐观锁:UPDATE带版本校验且检查ROW_COUNT是否为1。

PostgreSQL如何处理更新时的并发冲突_应用乐观锁逻辑与Version

PostgreSQL 更新时为什么会出现“覆盖丢失”?

想象这样一个场景:两个事务同时读取了同一行数据,各自在本地计算、修改,然后先后提交。结果呢?后提交的事务会直接覆盖前一个事务的变更,就像后者从未发生过一样。这就是所谓的“覆盖丢失”。

PostgreSQL 默认并不会阻止这种情况。即便是在 READ COMMITTED 隔离级别下,它也不保证“读-改-写”这个操作序列的原子性。这并非一个缺陷,而是数据库设计的权衡:它将并发冲突的检测和处理逻辑,交还给了应用层来决策。

version 字段实现乐观锁的正确写法

解决这个问题的核心思路,是引入一个版本号字段,让 UPDATE 操作自带版本校验。关键在于,不仅要检查版本条件,还必须确认更新是否真的成功了。仅仅依赖 WHERE version = ? 是不够的,后续对 ROW_COUNT 的检查才是胜负手。

  • 首先,表结构里需要增加一个 version 字段(INTBIGINT 类型),初始值设为 0。每次成功更新后,这个值自动加 1。
  • 应用层执行更新时,SQL 语句应该这样写:
    UPDATE accounts SET balance = 150, version = version + 1 WHERE id = 123 AND version = 42;
  • 语句执行后,必须立刻检查数据库返回的受影响行数。如果结果为 0,那就意味着在你读取版本号之后、执行更新之前,已经有其他事务抢先完成了修改。此时,当前操作应当视为失败,并触发重试或向用户返回明确的冲突错误。
  • 这里有一个常见的陷阱:不要在应用里先执行一次 SELECT version,然后在业务逻辑中拼接 SQL。这两个操作之间的时间窗口,足以让并发修改发生。正确的做法是,将版本判断和字段更新封装在一条原子的 UPDATE ... WHERE ... version = ? 语句中。

SELECT FOR UPDATE 和乐观锁不是一回事

千万别把两者搞混了。SELECT FOR UPDATE 是一种悲观锁策略。它会在读取时就直接锁定目标行,阻塞其他事务对该行的写操作,直到持有锁的事务结束。它主要解决的是“写-写冲突”的并发问题。

然而,悲观锁的代价是会降低系统的整体并发吞吐量。更重要的是,它无法防止应用层自身的逻辑错误,比如事务内读取数据、在应用服务中进行复杂计算、然后再写回时可能发生的错误。

相比之下,乐观锁采取的是另一种思路:它不加任何锁,而是通过版本号来检测数据在读取后是否被他人改动过。这种方案更适合那些读多写少、冲突概率相对较低的业务场景。

  • 使用 SELECT FOR UPDATE 时,务必确保在整个事务生命周期内都持有该锁,并且避免跨事务的分段操作。
  • 如果业务逻辑包含“先查询、再计算、最后更新”这样的长流程,同时又希望避免长时间阻塞其他请求,那么采用乐观锁配合 version 字段通常是更安全、更高效的选择。
  • 还有一个技术细节值得注意:在 REPEATABLE READ 隔离级别下,使用 SELECT FOR UPDATE 可能会触发序列化失败错误(could not serialize access due to concurrent update),而乐观锁机制则不会引发此类问题。

容易被忽略的细节:时钟无关、无需 UUID、别漏掉 RETURNING

实现乐观锁时,有几个细节一旦忽略,就可能埋下隐患。

首先,version 字段必须使用单调递增的整数,切忌依赖系统时间(如 NOW()CLOCK_TIMESTAMP())。在高并发场景或遇到服务器时钟回拨时,基于时间戳的版本判断会完全失效。

其次,方案不必复杂化。引入 UUID 或各种哈希算法并没有必要,一个简单的 INT 自增字段就足够可靠。

  • 一个小技巧:在 UPDATE 语句末尾加上 RETURNING version 子句。这样,一次查询就能直接获取到更新后的新版本号,省去了再次查询的开销。
  • 如果项目中使用 ORM 框架(如 SQLAlchemy、MyBatis),需要确认其是否原生支持基于 version 字段的乐观锁配置,而不是仅仅做了简单的字段映射。
  • 测试阶段至关重要。务必模拟并发场景进行验证:可以打开两个 psql 会话,手动执行带有相同旧版本号的 UPDATE 语句,直观地观察哪一个成功、哪一个返回 0 行受影响。

说到底,最困难的往往不是写出那行正确的 UPDATE 语句,而是确保所有可能修改这条数据的代码路径——无论是前端接口、后台定时任务,还是临时的数据迁移脚本——都严格遵循同一套版本校验逻辑。只要有一条路径漏掉了版本检查,整个乐观锁的防护就形同虚设了。

来源:https://www.php.cn/faq/2311981.html
上一篇Oracle如何查询被锁定的用户列表_通过DBA_USERS视图分析 下一篇Oracle的TNS名称无法解析怎么办_检查tnsnames.ora配置
本站内容用于信息整理与展示,如有侵权或内容问题请及时联系处理。

相关推荐

补充同频道和同主题内容,方便继续浏览更多相关内容。

同类最新

继续查看同栏目最近更新的文章。

更多
金仓数据库逻辑备份实战:全库导出与模式替换全流程
数据库 · 2026-07-03

金仓数据库逻辑备份实战:全库导出与模式替换全流程

在长期的运维实践中,我越来越体会到,备份就像一份保险——平时看似无用,但关键时刻却是唯一的救命稻草。逻辑备份看似简单,可真正执行恢复时,各种陷阱接连浮现:表名大小写不一致、Schema 未正确切换、Owner 属性未同步修改……任何一个环节处理不当,最终恢复出的数据库就会与预期相去甚远。 本文将深入

金仓数据库sys_rman物理备份全流程演练与误覆盖恢复
数据库 · 2026-07-03

金仓数据库sys_rman物理备份全流程演练与误覆盖恢复

干运维这行,逻辑备份和物理备份我都接触过,但说句实在话,真正能在生产环境里扛住事儿的,还得是物理备份。逻辑备份导出的是 SQL 语句,数据量一大,那速度慢得让人抓狂,而且最关键的是,它没法做时间点恢复。物理备份不一样,它直接拷贝数据文件,再配上 WAL 归档日志,想恢复到过去哪一秒都行,这是它最硬核

Windows下将MySQL注册为系统自启服务教程
数据库 · 2026-07-03

Windows下将MySQL注册为系统自启服务教程

先说一个关键前提:务必以管理员身份运行终端,否则 mysqld --install 这条命令几乎不可能成功。问题不在于命令写错,而是 Windows 系统的用户账户控制(UAC)机制会在中途拦截——在普通 CMD 或 PowerShell 窗口执行这条命令,要么直接提示 Access is deni

Mac版Navicat中快速对比两个数据库的表结构异同
数据库 · 2026-07-03

Mac版Navicat中快速对比两个数据库的表结构异同

直接说结论:Mac 版 Navicat 和 Windows 版在表结构比对逻辑上完全一致。但默认配置下,它确实无法承受“全库一键比对上万张表”的压力。要想避免卡死、内存溢出、进度条永远停在 0%,你必须手动将表分批处理,或者利用前缀过滤来控制扫描范围。 为什么 Mac 上点击「结构同步」后界面会卡住

MySQL中UNION操作推荐用UNION ALL的原因
数据库 · 2026-07-03

MySQL中UNION操作推荐用UNION ALL的原因

MySQL中UNION与UNION ALL性能对比:别再被“保险”迷惑,差距远超预期 先给出核心结论:UNION ALL 的性能通常比 UNION 高出不止一个数量级。原因在于,UNION 在合并结果集后会自动触发去重操作,这往往伴随着隐式排序,进而产生临时表和文件排序。而 UNION ALL 则直