Django 1.11.8中SubQuery查询过慢，如何在非FK关联下提速？

嘿，我来帮你搞定这个慢查询的问题！你的场景是典型的无外键关联下的跨表过滤，原SubQuery的方式确实会在数据量大的时候拖垮性能——本质是每个Lead对象都会触发一次独立的子查询，数据量上去后开销会指数级增长。结合你的Django 1.11.8和PostgreSQL 9.5环境，给你几个高效的优化方案：

虽然你的parcel字段已经设置了unique=True（PostgreSQL会自动为其创建唯一索引），但如果我们把parcel和livablesqft做成联合索引，数据库在查询时不用回表读取主表数据，直接从索引里就能拿到livablesqft的值，能大幅减少IO开销。

修改ResidentialMasterRecord模型添加索引：

class ResidentialMasterRecord(Model):
    parcel = CharField(max_length=10, unique=True)
    livablesqft = IntegerField(...)  # 根据你的实际字段类型调整
    lotsqft = ...

    class Meta:
        indexes = [
            models.Index(fields=['parcel', 'livablesqft']),
        ]

然后运行python manage.py makemigrations和migrate完成索引创建。这个小改动能让原SubQuery的执行效率提升不少。

原查询的SubQuery属于"N+1查询"的变种，换成数据库原生的JOIN会高效得多。因为Django 1.11没有内置无外键JOIN的ORM支持，我们可以用两种方式实现：

方式A：使用Raw SQL（最直接高效） #

直接写PostgreSQL支持的JOIN语句，跳过Django ORM的限制，数据库会生成最优的执行计划：

from myapp.models import Lead

qs = Lead.objects.raw('''
    SELECT l.*
    FROM myapp_lead l
    INNER JOIN myapp_ownershiprecord o 
        ON l.ownership_record_id = o.id
    INNER JOIN myapp_residentialmasterrecord r 
        ON o.parcel = r.parcel
    WHERE r.livablesqft >= 1500
''')

这个查询会一次性把三个表关联起来，过滤出符合条件的Lead，速度会比原SubQuery快几个数量级。如果需要获取livablesqft的值，只需在SELECT语句中加上r.livablesqft，之后就能通过RawQuerySet的对象属性直接访问。

方式B：用IN子查询替代SubQuery（无需写Raw SQL） #

如果不想写原生SQL，可以先筛选出符合面积要求的parcel列表，再关联Lead：

from myapp.models import Lead, ResidentialMasterRecord

# 先获取所有符合面积要求的parcel（仅执行一次子查询）
valid_parcels = ResidentialMasterRecord.objects.filter(livablesqft__gte=1500).values('parcel')

# 过滤Lead，只保留关联的OwnershipRecord在有效parcel列表内的记录
qs = Lead.objects.select_related('ownership_record').filter(ownership_record__parcel__in=valid_parcels)

这种方式的性能比原SubQuery好很多，因为IN子查询只会执行一次，而不是每个Lead都执行一次。不过如果valid_parcels的数量极大，IN子查询的性能可能不如JOIN，这时候优先选Raw SQL的方式。

如果你能在数据库层面给ResidentialMasterRecord.parcel和OwnershipRecord.parcel添加外键约束（不需要修改Django模型），PostgreSQL的查询优化器会更高效地处理关联查询，生成更优的执行计划。

通过psql或数据库管理工具执行以下SQL：

ALTER TABLE myapp_residentialmasterrecord
ADD CONSTRAINT fk_residential_parcel FOREIGN KEY (parcel) 
REFERENCES myapp_ownershiprecord(parcel);

注意：添加外键前要确保两个表的parcel字段数据完全一致，没有孤立记录，否则会报错。这个操作不会影响你的Django模型结构，完全符合你"保持非外键关联结构"的要求。

你可以用PostgreSQL的EXPLAIN ANALYZE命令查看原查询的瓶颈，比如是否存在全表扫描、有没有用到索引：

EXPLAIN ANALYZE
SELECT l.*, (SELECT r.livablesqft FROM myapp_residentialmasterrecord r WHERE r.parcel = o.parcel LIMIT 1) AS sqft
FROM myapp_lead l
JOIN myapp_ownershiprecord o ON l.ownership_record_id = o.id
WHERE sqft >= 1500;

通过执行计划你能精准定位性能瓶颈，针对性调整优化策略。

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