PostgreSQL中带WHERE和JOIN的UPDATE及函数实现是否具备原子性？

算力阿峰

2026-8-13

问题解答

首先看你给出的第一条SQL语句：

UPDATE table_A
SET col_1 = ... (some values)
WHERE exists (select col_2 from table_A join table_B On table_A.col_3 = table_B.col3)

一、这条UPDATE语句的原子性与并发行为

单个UPDATE语句在PostgreSQL中是原子操作，条件判断和更新执行是不可分割的整体：

原子性保障：要么所有符合WHERE EXISTS条件的行被更新，要么整个操作完全回滚，绝不会出现部分更新的情况。
并发场景下的执行逻辑：在默认的READ COMMITTED隔离级别下，UPDATE会基于语句启动瞬间的数据快照来判断EXISTS条件。如果其他用户在这条UPDATE启动后、完成前修改了table_A或table_B并提交，这些新修改不会被当前UPDATE的条件判断感知——只要启动时条件满足，更新就会执行。
反过来，如果其他事务在这条UPDATE启动前就提交了导致关联结果为空的修改，那EXISTS会返回false，不会执行任何更新。

再看你用PostgreSQL函数实现的逻辑：

Create function atomic_update(... --parameters)
...
BEGIN
select col_2 from table_A join table_B On table_A.col_3 = table_B.col3 into exists;
if exists
    -- do update
    update table_A where ...
else
    -- raise exception
END
...

二、这个函数逻辑的原子性

这种写法不具备原子性，因为SELECT判断和UPDATE是两个独立的语句，中间存在可被并发修改利用的时间窗口：

比如SELECT查询时关联结果非空，但在SELECT执行完、UPDATE开始前，其他用户修改了table_A或table_B导致关联失效，此时UPDATE仍然会执行，不符合你“仅当关联非空时更新”的要求。
要让函数逻辑原子化，有两种常见方案：
- 在SELECT语句末尾加上FOR UPDATE，锁定关联的table_A和table_B行，阻止其他事务在间隙中修改这些数据；
- 将事务隔离级别提升到SERIALIZABLE，强制事务串行执行，但会增加锁冲突的概率，影响并发性能。