Django select_for_update(skip_locked=True)跨表查询锁范围异常求助

尝试锁定查询集中最早的条目时遇到异常：

• 通过event__date、entry_type__name这类关联字段过滤时，整个符合条件的查询集都会被锁定
• 直接传入FK实例（Event和EntryType对象）过滤时，只会正确锁定最早的那条实例

异常代码示例（锁定整个查询集） #

with transaction.atomic():
   locked_entry = Entry.objects.select_for_update(skip_locked=True).filter(
                event__date=distribution_date(), 
                status='pending',
                entry_type__name='Premium'
            ).order_by('-created_at').first()
    print(locked_entry)
    sleep(4)

正常代码示例（仅锁定目标条目） #

with transaction.atomic():
   locked_entry = Entry.objects.select_for_update(skip_locked=True).filter(
                event=Event.objects.get(date=distribution_date()), 
                status='pending',
                entry_type=EntryType.objects.get(name='Premium')
            ).order_by('-created_at').first()
    print(locked_entry)
    sleep(4)

原因解释 #

核心差异在于Django生成的SQL执行逻辑：

• 关联字段过滤（event__date/entry_type__name）：
  Django会生成带JOIN的SQL，先关联Event、EntryType表完成过滤，再对匹配的Entry行执行SELECT ... FOR UPDATE SKIP LOCKED。部分数据库（如PostgreSQL）处理这类带JOIN的锁语句时，会先锁定所有匹配的Entry行，再执行ORDER BY和LIMIT 1，最终导致整个查询集被锁定。

• FK实例过滤（event=xxx/entry_type=xxx）：
  过滤条件基于Entry表的外键ID（如event_id=123），生成的SQL会先对Entry表完成条件过滤，直接执行ORDER BY created_at DESC LIMIT 1锁定唯一匹配的行，因此只会锁定目标条目。

验证方法 #

可以通过query属性查看两段代码生成的SQL差异，确认JOIN的存在：

# 查看关联过滤的SQL
print(Entry.objects.select_for_update(skip_locked=True).filter(
    event__date=distribution_date(), 
    status='pending', 
    entry_type__name='Premium'
).order_by('-created_at').query)

# 查看FK实例过滤的SQL
print(Entry.objects.select_for_update(skip_locked=True).filter(
    event=Event.objects.get(date=distribution_date()), 
    status='pending', 
    entry_type=EntryType.objects.get(name='Premium')
).order_by('-created_at').query)

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