Django ListView页面加载过慢 外键查询性能优化方案咨询

你的判断完全正确，当前113s的超长加载耗时是典型的N+1查询问题：默认的ListView拉取Combination列表时只会执行1次SQL查询获取所有Combination记录，模板渲染过程中每访问一次外键关联对象，就会单独发起一次SQL查询。按你当前的模板和模型__str__逻辑，单条Combination渲染需要查询subsidiary、department、sub_budget、budget_owner，以及budget_owner下关联的两个Person对象，也就是单条记录会触发5次额外查询。如果列表有上千条记录，总查询次数会达到数千次，直接导致请求耗时飙升。

核心优化：使用select_related预加载关联外键 #

select_related会在首次查询时通过SQL JOIN一次性拉取所有关联外键的表数据，把成百上千次零散查询压缩为1次，是解决这类ForeignKey关联查询性能问题的首选方案。
你只需要重写ListView的get_queryset方法即可，修改views.py代码：

class CombinationListView(LoginRequiredMixin, ListView):
    model = Combination
    template_name = "budget/combination_list.html"

    def get_queryset(self):
        # 注意必须预加载到SubBudgetOwner关联的Person层级，否则__str__渲染时仍会触发额外查询
        return super().get_queryset().select_related(
            "subsidiary",
            "department",
            "sub_budget",
            "budget_owner",
            "budget_owner__budget_owner",
            "budget_owner__sub_budget_owner"
        )

注意：不要遗漏budget_owner__budget_owner和budget_owner__sub_budget_owner两层预加载，因为SubBudgetOwner的__str__方法直接调用了这两个关联Person对象，漏写的话优化效果会打折扣。

进阶优化：分页控制单页数据量 #

如果Combination表总数据量超过1000条，即使做了JOIN查询，单条SQL拉取全量数据也会有性能瓶颈，直接开启Django原生分页即可，单页加载50-200条数据对用户浏览和数据库压力都更友好：

class CombinationListView(LoginRequiredMixin, ListView):
    model = Combination
    template_name = "budget/combination_list.html"
    paginate_by = 100 # 单页展示100条，可根据业务需求调整

    def get_queryset(self):
        return super().get_queryset().select_related(
            "subsidiary",
            "department",
            "sub_budget",
            "budget_owner",
            "budget_owner__budget_owner",
            "budget_owner__sub_budget_owner"
        )

开启分页后只需要在模板中补充分页导航控件即可正常使用。

可选优化：按需拉取字段减少数据传输量 #

如果关联表的字段很多，而列表渲染只用到__str__涉及的名称类字段，可以搭配only()方法指定需要拉取的字段，进一步降低SQL查询返回的数据体积，适合数据量较大的场景：

def get_queryset(self):
    return super().get_queryset().select_related(
        "subsidiary",
        "department",
        "sub_budget",
        "budget_owner",
        "budget_owner__budget_owner",
        "budget_owner__sub_budget_owner"
    ).only(
        "id",
        "subsidiary__name",
        "department__name",
        "sub_budget__name",
        # 下方替换为你Person模型中存储姓名的实际字段名，比如full_name/name
        "budget_owner__budget_owner__full_name",
        "budget_owner__sub_budget_owner__full_name"
    )

效果验证 #

修改完成后刷新页面，通过debug toolbar查看SQL面板，总查询数会从原来的数百/数千次降到个位数，正常情况下总请求耗时会降到100ms以内，完全解决之前的超长加载问题。

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