Python的Django ORM把我坑惨了，原来select_related和prefetch_related的区别这么大

上个月帮同事看一个 Django 接口的性能问题。页面加载要七八秒，他定位到是某个列表页查询太慢。代码大概长这样：

orders = Order.objects.filter(status='paid')
for order in orders:
   print(order.user.username)      # 访问关联的 User
   for item in order.items.all():  # 访问关联的 OrderItem
       print(item.product.name)    # 再访问 OrderItem 的 Product


他说：“Django 的 ORM 不是自动处理关联查询吗？我直接用点号访问，多方便。”

是方便。但每次点号访问，只要关联对象还没被加载，Django 就会单独发一条 SQL 去数据库取。

一个订单列表页，假设有 200 个订单，每个订单 5 个商品，涉及 100 个用户。那么：

• 取订单：1 条 SQL
• 每个订单取用户：200 条 SQL
• 每个订单取商品项：200 条 SQL
• 每个商品项取商品：1000 条 SQL

加起来 1401 条 SQL。每条 SQL 哪怕只花 5 毫秒，也要 7 秒多。这就是典型的 N+1 查询问题。不是数据库慢，是查询次数太多。

解决办法就是 select_related 和 prefetch_related。但这两个名字长得像、功能描述也像——“都是用来减少查询次数的”。很多人随便挑一个用，结果要么没效果，要么报错，要么内存暴涨。

先搞清楚外键在数据库里长什么样

要理解两者的区别，得先回到数据库层面看关联关系是怎么存的。

以订单和用户为例：

class User(models.Model):
   username = models.CharField(max_length=100)

class Order(models.Model):
   user = models.ForeignKey(User, on_delete=models.CASCADE)
   status = models.CharField(max_length=20)
   created_at = models.DateTimeField(auto_now_add=True)


Order 表里有一个 user_id 字段，存的是用户表的主键。这是一个多对一关系：多个订单可以属于同一个用户，每个订单只有一个用户。

当 Django 执行 order.user 的时候，它看到 Order 实例的 user_id 是 5，但 user 对象还没加载，于是发一条 SQL：

SELECT * FROM user WHERE id = 5;


如果循环里对每个订单都这么做，就是 N 条额外 SQL。

select_related 解决的就是这个问题。它告诉 Django：“在取订单的时候，顺便把关联的用户也取出来。” Django 会用 SQL 的 JOIN 把两张表连起来，一次查询拿到所有数据：

SELECT order.*, user.*
FROM order
INNER JOIN user ON order.user_id = user.id
WHERE order.status = 'paid';


拿到结果后，Django 在内存里把每一行拆成 Order 和 User 两个对象，并建立好引用。之后 order.user 直接返回已经加载好的对象，不再发 SQL。

一次 JOIN 查询代替了 N+1 条查询。

多对多和反向关系，JOIN 搞不定

现在看订单和商品项的关系：

class OrderItem(models.Model):
   order = models.ForeignKey(Order, on_delete=models.CASCADE)
   product = models.ForeignKey(Product, on_delete=models.CASCADE)
   quantity = models.IntegerField()


OrderItem 有外键指向 Order。反过来，一个订单可以有多个订单项。从 Order 到 OrderItem 是一个一对多的反向关系。

Django 默认给反向关系起名叫 orderitem_set，但如果 ForeignKey 里设置了 related_name='items'，就可以用 order.items.all() 访问。

问题来了：select_related 能不能用在 order.items.all() 上？

不能。select_related 只能用于单值关系，也就是 ForeignKey 和 OneToOneField。因为 JOIN 之后，一行订单对应一行用户，一对一，不会产生重复行。

但 order.items.all() 是一对多，一个订单对应多个订单项。如果硬用 JOIN：

SELECT order.*, orderitem.*
FROM order
INNER JOIN orderitem ON orderitem.order_id = order.id;


一个订单有 5 个订单项，结果集里就会出现 5 行。Django 拿到这 5 行后，需要把它们合并成一个 Order 对象，再把 5 个 OrderItem 挂上去。这可行，但如果有多个一对多关系同时 JOIN，行数会乘法式膨胀，性能反而更差。

所以 Django 对多对多和反向一对多提供了另一个工具：prefetch_related。

prefetch_related 走的是另一条路

prefetch_related 不用 JOIN。它的做法是分两步查询，然后在 Python 层面做匹配。

还是用订单和订单项举例：

orders = Order.objects.prefetch_related('items').filter(status='paid')


Django 会执行两条 SQL：

第一条，取所有订单：

SELECT * FROM order WHERE status = 'paid';


假设拿到 200 个订单，ID 是 1 到 200。

第二条，取这些订单的所有订单项：

SELECT * FROM orderitem WHERE order_id IN (1, 2, 3, ..., 200);


一条 SQL 把所有相关订单项都取回来。

然后在 Python 里，Django 遍历这 200 个订单项，根据每项的 order_id，把它挂到对应的 Order 对象的 _prefetched_objects_cache 里。之后再访问 order.items.all()，直接返回缓存好的列表，不再发 SQL。

总共 2 条 SQL，而不是 201 条。

prefetch_related 还能继续往下预取。比如订单项里还有 product 外键：

orders = Order.objects.prefetch_related('items__product')


它会发三条 SQL：取订单、取订单项、取商品。然后在 Python 里把 OrderItem 和 Product 关联起来。比用 select_related 做多层 JOIN 更可控，也更省内存。

核心区别：一条 SQL 还是两条 SQL

现在可以做个清晰的对比了：

一句话总结：select_related 用 JOIN 一次拿完，适合单值关系；prefetch_related 分两次拿，适合多值关系。

判断标准很简单：关联对象只有一个，用 select_related；关联对象有多个，用 prefetch_related。

order.user 是单个用户，用 select_related('user')。order.items.all() 是多个订单项，用 prefetch_related('items')。user.order_set.all() 是反向多个订单，用 prefetch_related('order_set')。

用错了会怎样

用 prefetch_related 去预取一个 ForeignKey 行不行？行，但没必要。它会多发一条 SQL，虽然也能工作，但比 select_related 多一次数据库往返。

用 select_related 去预取多对多呢？直接报错：

FieldError: Cannot resolve keyword 'items' into field. Choices are: ...


Django 在解析 select_related 的参数时，只会查 ForeignKey 和 OneToOneField。遇到多对多或反向关系，它找不到对应的字段，直接抛异常。

还有一种常见错误：在 prefetch_related 里套 select_related 的语法：

Order.objects.prefetch_related('user__profile')  # 可以，会分步预取
Order.objects.select_related('items__product')   # 报错，items 不是单值关系


如果一条链路上既有单值又有多值，可以混用：

Order.objects.select_related('user').prefetch_related('items__product')


Django 会先 JOIN 用户，再分步预取订单项和商品。这是处理复杂关联的标准写法。

Prefetch 对象：更精细的控制

prefetch_related 默认会把关联对象的全部字段和全部记录都取回来。如果关联数据量很大，或者你只需要其中一部分，可以用 Prefetch 对象做精细控制。

from django.db.models import Prefetch

orders = Order.objects.prefetch_related(
   Prefetch(
       'items',
       queryset=OrderItem.objects.filter(quantity__gt=1).select_related('product'),
       to_attr='big_items'
   )
)


这里做了三件事：

1. 只预取 quantity > 1 的订单项，不是全部。
2. 预取时顺便用 select_related 把 product 也加载了，避免后续再查。
3. 结果存到 order.big_items 这个自定义属性里，而不是默认的 order.items。

之后用 order.big_items 访问，得到的是一个列表，已经过滤好、关联好，且不再触发 SQL。

Prefetch 的价值在于：它让你在“分步查询”这个框架里，仍然能对第二步查询做定制。这是 select_related 做不到的——JOIN 的 SQL 由 Django 生成，你很难在中间插条件。

性能对比：不只是 SQL 条数

很多人以为 select_related 一定比 prefetch_related 快，因为 SQL 条数少。这不一定。

select_related 用 JOIN，如果关联表很大，或者关联链很长，JOIN 出来的结果集可能非常宽。比如 select_related('user', 'product', 'address', 'payment')，每行订单都会带上四张表的全部字段。字段越多，网络传输和内存解析的开销越大。

prefetch_related 分步查，每条 SQL 只取一张表的字段，结果集更干净。在关联数据量大、字段多的情况下，反而可能更快。

另一个因素是索引。JOIN 的 ON 条件如果没有索引，数据库要做全表扫描。而 prefetch_related 的 IN 查询通常能用到主键索引，效率很高。

所以选择依据不是“哪个更快”，而是“哪个正确”。单值关系用 select_related，多值关系用 prefetch_related。这是由关系类型决定的，不是性能调优的结果。

一个真实场景

我之前维护一个博客系统，首页要展示最新的 20 篇文章，每篇文章显示作者名、分类名、标签列表、评论数。

最初的代码：

posts = Post.objects.all()[:20]
for post in posts:
   print(post.author.username)
   print(post.category.name)
   for tag in post.tags.all():
       print(tag.name)
   print(post.comments.count())


author 和 category 是外键，可以用 select_related。tags 是多对多，comments 是反向一对多，需要用 prefetch_related。

优化后：

posts = Post.objects.select_related('author', 'category').prefetch_related('tags', 'comments')[:20]


SQL 从 1 + 20 + 20 + 20 + 20 = 81 条降到 1 + 20 + 20 + 20 = 61 条？不是。

select_related 把 author 和 category 合并进第一条 SQL，所以取文章是 1 条。prefetch_related('tags') 是 1 条：SELECT * FROM tag WHERE post_id IN (...)。prefetch_related('comments') 是 1 条：SELECT * FROM comment WHERE post_id IN (...)。

总共 3 条 SQL。页面加载从 4 秒降到 200 毫秒。

注意 comments.count() 的问题。prefetch_related('comments') 会把所有评论对象加载到内存，如果只是想显示数量，用 annotate 更合适：

from django.db.models import Count

posts = Post.objects.select_related('author', 'category').prefetch_related('tags').annotate(comment_count=Count('comments'))[:20]


这样评论数由数据库直接算好，不用把评论对象全部取回来。prefetch_related 适合“需要访问关联对象本身”的场景，annotate 适合“只需要聚合值”的场景。

怎么发现 N+1

Django Debug Toolbar 是最直观的工具。装好之后，页面侧边栏会显示每个请求执行了多少条 SQL。如果看到几十上百条相似结构的查询，基本就是 N+1。

没有 toolbar 的话，可以用 connection.queries：

from django.db import connection

# 执行查询
list(orders)

print(len(connection.queries))
for q in connection.queries:
   print(q['sql'])


connection.queries 只在 DEBUG=True 时记录，生产环境不适用。生产环境可以用 django-silk 或者 APM 工具做 SQL 监控。

还有一个办法：在测试里断言查询次数。

from django.test import TestCase
from django.assertNumQueries import assertNumQueries

class OrderTest(TestCase):
   def test_order_list_queries(self):
       with self.assertNumQueries(3):
           orders = Order.objects.select_related('user').prefetch_related('items')
           for order in orders:
               order.user.username
               list(order.items.all())


如果实际查询次数和预期不符，测试直接失败。这个方法能把 N+1 挡在上线之前。

什么时候不用预取

预取不是越多越好。有几个场景要谨慎：

第一，关联数据量极大。比如一篇热门文章有十万条评论，prefetch_related('comments') 会一次性把十万条评论全部加载到内存，直接 OOM。这时候应该分页，或者用 annotate 只取数量。

第二，预取了但没用到。select_related 和 prefetch_related 都有开销。如果某个关联对象在后续逻辑里根本没被访问，预取就是浪费。只预取确定会用到的关系。

第三，查询集只取一条记录。Post.objects.get(id=1) 本身只发一条 SQL，即使有 N+1，N 也是 1。预取的意义不大。预取主要在列表页、循环访问的场景下发挥作用。

最后

select_related 和 prefetch_related 的区别，本质上是单值关系和多值关系的区别，是一条 JOIN 和分步查询的区别。

名字像，但适用场景不重叠：ForeignKey 和 OneToOneField 用 select_related，ManyToManyField 和反向 ForeignKey 用 prefetch_related。混用、用错，轻则没效果，重则报错或内存暴涨。

处理列表页的时候，习惯性地问自己：这个循环里访问了哪些关联对象？它们是单个还是多个？单个的进 select_related，多个的进 prefetch_related。再配上 assertNumQueries 写个测试，N+1 就再也坑不到你了。