PostgreSQL Serializable事务未按预期工作：任务分配重复问题

听起来你遇到了典型的并发任务领取坑——哪怕用上了SERIALIZABLE隔离级别还是出现了重复分配，其实核心问题往往不是隔离级别本身，而是你的事务逻辑有没有做到真正的原子性，或者有没有利用数据库原生约束兜底。

先拆解下可能的原因：

• 是不是你的领取逻辑分两步走：先查tasks里未被分配的任务，再往assigned插记录？哪怕是SERIALIZABLE级别，这种"读-插"的分离操作还是会留下竞态窗口——两个事务可能同时读到同一个未分配任务，接着都往assigned里插数据。
• 部分数据库的SERIALIZABLE实现基于快照隔离（比如PostgreSQL的SSI），它会在事务提交时检查串行化冲突，但如果你的逻辑没触发冲突检测条件，还是可能允许重复提交。

下面给你几个靠谱的解决方案，按优先级排序：

1. 加唯一约束兜底（最可靠） #

直接给assigned表的_task字段加唯一约束，从数据库层面彻底杜绝同一个任务被多次分配：

ALTER TABLE assigned ADD CONSTRAINT unique_task_assignment UNIQUE (_task);

不管业务逻辑有没有疏漏，只要出现重复插入_task的操作，数据库都会直接抛出唯一约束违反的错误，你只需要在代码里捕获这个错误，重新领取其他任务就行。这是最安全的兜底方案，一定要加上。

2. 用原子化的任务选取逻辑 #

把"查询可用任务+标记已分配"变成一个原子操作，掐掉中间的竞态窗口。可以用SELECT ... FOR UPDATE SKIP LOCKED（MySQL 8.0+、PostgreSQL 9.5+都支持）：

-- 锁定一个未被分配的任务，跳过已被其他事务锁定的任务
SELECT t._id FROM tasks t
LEFT JOIN assigned a ON t._id = a._task
WHERE a._task IS NULL
LIMIT 1
FOR UPDATE SKIP LOCKED;

-- 紧接着插入分配记录
INSERT INTO assigned (_id, _task) VALUES ('新分配ID', '刚才选中的任务ID');

SKIP LOCKED会让当前事务直接跳过已被锁定的任务，选取下一个可用的，从根源上避免多个事务选中同一个任务。记得把整个逻辑放在同一个事务里执行。

3. 合并查询与插入操作 #

如果不想用SKIP LOCKED，也可以把查询和插入合并成单条SQL，确保操作的原子性：

INSERT INTO assigned (_id, _task)
SELECT '新分配ID', t._id
FROM tasks t
LEFT JOIN assigned a ON t._id = a._task
WHERE a._task IS NULL
LIMIT 1;

单条SQL的执行是数据库层面保证原子性的，不会出现竞态问题。

额外检查点 #

• 确保领取任务的完整流程都包裹在同一个事务里，别拆分成多个事务执行。
• 如果用的是MySQL，注意SERIALIZABLE级别下的锁机制，它会对扫描到的行加锁，可能需要给查询语句加合适的索引，避免全表扫描导致锁范围过大。

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