InnoDB锁机制与事务模型验证：并发场景下锁行为问询

我仔细梳理了你描述的整个流程，你的分析精准命中了InnoDB在处理这类竞态分配场景时的核心逻辑，不过我可以补充几个关键细节帮你更深入理解底层机制：

• UPDATE语句的锁获取逻辑：InnoDB执行带WHERE条件的UPDATE时，会先通过可用索引（这里ORDER BY id用到了主键索引）定位符合条件的记录，然后对匹配的记录加排他记录锁（X锁）。P1的UPDATE先找到r1并加锁，T1未提交时，P2的UPDATE在扫描到r1时尝试加X锁失败，会进入锁等待队列，而不是直接跳过r1。
• 事务提交后的锁释放与条件重评估：当T1提交后，r1上的X锁会立即释放。此时T2的UPDATE会重新评估WHERE条件（即使是默认的REPEATABLE READ隔离级别，InnoDB在执行更新操作时也会读取最新的数据快照并重新检查条件），发现r1已不符合status='queuing' AND pid IS NULL的要求，于是继续扫描到r2，对其加锁并完成更新。
• LIMIT 1的关键作用：这个参数是整个竞态分配逻辑的核心保障——它确保每个UPDATE只会尝试锁定并更新一条符合条件的记录。如果没有LIMIT 1，P1的UPDATE会一次性锁定所有queuing状态的记录，导致P2完全无法执行任何更新，直到T1提交，这显然不符合你想要的“分布式分配”的需求。
• 事务内SELECT的可见性：P1在T1中执行的SELECT * FROM requests WHERE status = 'processing' AND pid = '1'，能读取到自己事务中未提交的修改，这是InnoDB MVCC的特性：事务可以看到自身已做的变更，无需等待提交。而T1提交后，所有事务都能看到r1的状态变更。

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