PostgreSQL中更新单条钱包表行时如何让SELECT请求排队？

在PostgreSQL默认的Read Committed隔离级别下，SELECT会读取行的快照数据（即更新前的旧值），不会等待正在进行的UPDATE事务。要让getWallet()在updateWallet()执行时等待并读取最新值，可通过以下数据库层方案实现：

1. 给SELECT语句加行锁（推荐） #

在getWallet()的查询中使用SELECT ... FOR UPDATE或SELECT ... FOR SHARE，主动获取目标行的锁，与updateWallet()持有的排他锁产生冲突，迫使SELECT等待UPDATE事务提交后再执行。

示例代码 #

• getWallet()的SQL：

SELECT balance FROM wallet WHERE user_id = $1 FOR UPDATE;

• updateWallet()的SQL（无需额外修改，UPDATE本身会自动获取行的排他锁）：

UPDATE wallet SET balance = $1 WHERE user_id = $2;

原理说明 #

• UPDATE操作会对目标行加排他锁，直到事务提交才释放。
• SELECT ... FOR UPDATE会请求目标行的排他锁，当该行被其他事务持有排他锁时，这个SELECT会进入等待队列，锁释放后执行时就能读取到更新后的最新值。
• 若不想获取排他锁（避免影响其他需要共享锁的操作），可改用SELECT ... FOR SHARE，它请求共享锁，同样会被UPDATE的排他锁阻塞，达到等待更新完成的效果。

2. 调整事务隔离级别 #

将getWallet()所在事务的隔离级别提升到Serializable，这是PostgreSQL最严格的隔离级别，会强制事务串行执行，确保SELECT不会读取未提交的更新数据，而是等待更新事务完成后再读取。

示例代码 #

在getWallet()的事务开始时设置隔离级别：

BEGIN;
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SELECT balance FROM wallet WHERE user_id = $1;
COMMIT;

注意事项 #

• Serializable隔离级别会增加数据库锁竞争，可能导致性能下降，适合对数据一致性要求极高的场景。
• 该方式会影响所有该隔离级别下的SELECT操作，灵活性不如行锁方案。

关键注意点 #

• 控制事务时长：updateWallet()的事务要尽量短，避免长时间持有锁导致getWallet()等待过久，影响系统吞吐量。
• 死锁预防：如果存在多操作的事务，确保所有事务对行的锁定顺序一致（比如先锁user_id小的行，再锁大的），避免出现死锁。

内容的提问来源于stack exchange，提问作者mehmet degirmenci