带LIMIT 1的UPDATE WHERE IN语句为何会意外更新多行队列项？

• 核心诱因是PostgreSQL查询规划器对同表带行锁子查询的特殊优化逻辑，完全打破了预期的执行流程。
• 你原本设计的预期执行流程是：先通过子查询扫描符合条件的待处理队列行，跳过被其他事务锁定的行，按优先级排序后仅取1条记录的id加行锁，再把这单个id传给外层UPDATE，定位对应行完成状态更新。
• 出现异常时的实际执行流程是：当队列表中符合筛选条件（delay满足、状态为待处理）的待处理数据量达到一定阈值，规划器会自动合并子查询和外层UPDATE的同表操作逻辑：直接扫描所有符合基础筛选条件的行，加SKIP LOCKED行锁，紧接着对所有被锁定的行执行状态更新，整个过程中完全丢弃了子查询里的LIMIT 1限制，最终造成一次性更新多行的问题。
• 主键id无法避免这个异常的原因：在异常触发的执行路径下，规划器根本不会使用子查询返回的单个id做主键定位回表，而是直接把同表的筛选条件合并到外层更新的WHERE子句中，主键的唯一性约束完全不参与执行流程，自然无法限制更新的行数。
• 异常表现为“有时复现”的原因：规划器选择执行路径的依据是成本估算结果，当符合条件的待处理队列行数很少时，会走你预期的单行处理路径，功能完全正常；当数据量增长到规划器判定批量锁定更新的整体成本更低时，就会切换到上述异常执行路径，表现出随机更新多行的问题。

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