prefetch_related能解决N+1查询，因其通过一次额外IN查询批量加载多值关联数据并在Python层拼接。它适用于ManyToManyField和反向ForeignKey，而select_related仅支持单值关系的JOIN查询。
prefetch_related 为什么能解决 N+1 查询
当你用 ForeignKey 或 ManyToManyField 关联查询时，Django 默认会在循环中逐条触发 SQL（比如遍历 100 个文章对象，再为每个对象查一次作者），导致 1 + 100 次查询。而 prefetch_related 会把关联数据「预先批量查好」，用一次额外的 JOIN 或独立查询加载全部关联对象，再在 Python 层完成拼接——本质是用空间换时间，避免重复数据库往返。
什么时候必须用 prefetch_related 而不是 select_related
select_related 只支持单值关系（ForeignKey、OneToOneField），靠 SQL JOIN 实现；prefetch_related 支持多值关系（ManyToManyField、反向 ForeignKey），用的是额外的 IN 查询 + 内存映射。如果你遇到以下情况，prefetch_related 是唯一选择：
- 要查某篇文章的所有标签（
Article.tags.all()） - 要查某个用户发表的所有评论（
User.article_set.all()，反向外键） - 关联字段是
ManyToManyField且你没定义through模型
prefetch_related 的常见误用和修复方式
最常踩的坑是「嵌套预取写错路径」或「对已求值的 QuerySet 重复调用」：
- 错误：写成
prefetch_related('author__profile')却忘了author是正向外键——这里该用select_related更高效，prefetch_related对正向一对一/外键也能用，但没必要 - 错误：先执行
list(articles)再调用prefetch_related——QuerySet 已被求值，预取失效 - 正确做法：链式调用，在最终
.all()或.filter()后立即加prefetch_related，例如：Article.objects.filter(published=True).prefetch_related('tags', 'comments') - 进阶：对反向多对多加过滤，用
Prefetch对象：from django.db.models import Prefetch<br>Article.objects.prefetch_related(<br> Prefetch('comments', queryset=Comment.objects.filter(is_public=True))<br>)
性能对比和调试技巧
不加预取时，Django Debug Toolbar 会显示大量重复的 SELECT ... FROM comment WHERE article_id = ?；加了 prefetch_related 后，你会看到一条类似 SELECT ... FROM comment WHERE article_id IN (1,2,3,...) 的查询。注意两点：
立即学习“Python免费学习笔记（深入）”；
- 预取字段越多，内存占用越高，尤其当关联对象本身带大字段（如
TextField）时，要权衡是否真的需要全部字段 - 如果关联表数据量极大（比如某用户有 50 万条评论），
prefetch_related的IN查询可能触发 MySQL 的max_allowed_packet限制，此时得拆成多次小批量查询，或改用select_related+ 数据库视图
真正难处理的是跨多层、带条件、又涉及聚合的场景——这时候不能只靠 prefetch_related，得结合 annotate、values_list 或原生 SQL。
