破解 Django N+1 查询困境：使用 select_related 与 prefetch_related 实践指南
破解 Django N+1 查询困境：使用 select_related 与 prefetch_related 实践指南
开篇引入
数据库查询性能常常是 Web 应用性能瓶颈中的重中之重。Django ORM 以简洁直观的 API 层将 Python 代码与数据库打通，却也可能因默认的惰性加载带来 N+1 查询问题，造成不必要的网络往返和性能损耗。本文立足实际项目经验，从概念解析到实战案例，手把手教你识别、定位并解决 N+1 查询陷阱，帮助初学者入门、资深开发者再上层楼。
写这篇文章的初衷在于分享多年在多种业务场景中摸索出的 ORM 优化心得。你将看到典型的 N+1 查询示例、使用 Django Debug Toolbar 进行排查的方法，以及利用 select_related 与 prefetch_related 两大武器实现真正的预加载。希望这份指南能提升你的开发效率，让数据库操作不再成为性能绊脚石。
1 理解 N+1 查询问题
N+1 查询指在获取一条主记录之后，针对每条主记录再发起一次子记录查询的模式。举例来说，当你获取 10 篇文章（Article）后，再为每篇文章加载作者（Author），就会产生 1 次加载列表的查询 + 10 次加载作者的查询，共 11 次，这就是 N+1 查询。
这种查询模式在记录量较小的开发环境中可能不易察觉，但一旦数据量放大，数据库连接与网络延迟会急剧上升。每次额外的子查询不仅延长请求响应时间，也给数据库带来更高的并发压力