主要观点：在 PostgreSQL 中发现使用带有DELETE...RETURNING和LIMIT的公共表表达式（CTE）处理队列表中的一批项目时出现意外行为，看似简单的查询与查询规划器有令人惊讶的交互。
关键信息：

• 有一个task_queue表，通过 CTE 拉取特定queue_group_id的一个任务，预期RETURNING子句最多返回一个item_id，但实际有时会返回多个。
• 使用EXPLAIN ANALYZE发现规划器将查询转换为Nested Loop Semi Join，子查询（含LIMIT 1）对每个外扫描的候选行执行，导致多次删除和返回行。
• 解释了间歇性出现问题的原因，规划器的选择取决于表统计、数据分布等因素。
• 提供解决方案，通过在WHERE子句中直接使用子选择避免 CTE 来强制LIMIT全局应用，以确保期望的行为。
  重要细节：
• 初始查询结构及各部分作用，如WITH deleted_tasks AS (DELETE...FOR UPDATE SKIP LOCKED) SELECT item_id FROM deleted_tasks;。
• EXPLAIN ANALYZE输出中展示的规划器执行策略细节，如Nested Loop Semi Join、子查询执行次数等。
• 半连接优化的原理及对查询执行的影响，即子查询随外扫描候选行多次执行。
• 解决方案中修改后的查询结构DELETE FROM task_queue WHERE id = (SELECT...LIMIT 1) RETURNING item_id;及注意事项。