我发现了问题。这是因为在执行更新操作时，orm在默认情况下更新时间戳字段（为了简化上面的示例，我将它们从表结构中删除），关闭后死锁消失。但我还是不明白 updated_at 字段可能会导致问题，因为我仍在更新其他字段

表达式 offer_id%5 = :process_number 无法使用索引，因此它只能扫描与第一个条件匹配的所有行， worker_id is null .
你可以用两个窗口来证明这一点：

mysql1> begin;
mysql1> set @p=1;
mysql1> update offers set worker_id = @p where worker_id is null and offer_id%5 = @p;

不要在窗口1中提交事务。

mysql2> set @p=2;
mysql2> update offers set worker_id = @p where worker_id is null and offer_id%5 = @p;
...waits for about 50 seconds, or value of innodb_lock_wait_timeout, then...
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

这表明每个并发会话都会锁定重叠的行集，而不仅仅是匹配模表达式的行。所以会话排队时会碰到对方的锁。
如果你像@sloather建议的那样把所有步骤都放到一个事务中，情况会变得更糟。使每个工人的工作花费更长的时间将使他们只持有他们的锁的时间更长，并进一步延迟等待这些锁的其他进程。
我不明白更新的\u at字段是如何导致问题的，因为我仍在更新其他字段
我不确定，因为你还没有发布innodb死锁诊断 SHOW ENGINE INNODB STATUS .
我注意到您的表有一个辅助唯一键，这也需要锁。由于锁分配的非原子性，有时会出现死锁。

Worker 1                               Worker 2            

UPDATE SET worker_id = 1
(acquires locks on PK)

                                        UPDATE SET worker_id = 2
                                        (waits for PK locks held by worker 1)

(waits for locks on UNIQUE KEY)

因此，worker 1和worker 2可以互相等待，并进入死锁。
这只是猜测。另一种可能性是orm正在对 updated_at 列，这将引入另一个竞争条件的机会。我心里还没想清楚，但我认为这是可能的。
以下是为避免这些问题的不同系统提供的建议：
还有一个问题，你没有真正平衡工作与过程，以达到最佳的完成时间。按模数拆分时，每组中的报价数量可能不相等。而且每一个报价可能不会花费相同的时间来处理。因此，当最后一个工人仍在处理其工作时，您的一些工人可以完成工作而无事可做。
您可以同时解决锁定和负载平衡两个问题：
按以下方式更改表列：

ALTER TABLE offers
  CHANGE worker_id work_state ENUM('todo', 'in progress', 'done') NOT NULL DEFAULT 'todo',
  ADD INDEX (work_state),
  ADD COLUMN updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  ADD INDEX (updated_at);

创建一个进程，定期从表中读取数据，并添加主键 id 消息队列中处于“todo”状态的提供的值。所有的报价，不管其报价的id值是多少，都以相同的方式排队。

SELECT id FROM offers WHERE work_state = 'todo'
/* push each id onto the queue */

然后每个工人都可以拉一个 id 一次从消息队列中删除。工人对每个id执行以下步骤： UPDATE offers SET work_state = 'in progress' WHERE id = :id 工人只为一份工作而工作。 UPDATE offers SET work_state = 'done' WHERE id = :id 这些worker查询一次只引用一个offer，它们通过主键处理offer，主键将使用pk索引，一次只锁定一行。
一旦它完成了一个报价，那么工人就从队列中提取下一个报价。
这样，工人们就可以同时完成工作，而且工作会比工人们更好地平衡。此外，您可以随时启动或停止员工，而且您不必关心他们的员工编号，因为您的招聘不需要由与招聘id模数相同的员工处理。
当工作人员完成所有提供时，消息队列将为空。大多数消息队列允许worker执行阻塞读取，因此当队列为空时，worker将只等待读取返回。当你使用一个数据库时，工人们必须经常投票寻找新的工作。
一个工人在工作中很可能会失败，而且永远不会把一份工作标为“完成”。你需要定期检查孤立的提议。假设它们不会完成，并将其状态标记为“todo”。

UPDATE offers SET work_state = 'todo' 
WHERE work_state = 'in progress' AND updated_at < NOW() - INTERVAL 5 MINUTE

选择间隔长度，这样就可以确定，除非出了什么问题，否则任何工人都会在那个时候完成它。您可能会在dispatcher查询当前提供的todo之前执行此“重置”，以便将忘记的提供重新排队。