在Django ORM中select_related和prefetch_related之间有什么区别？

Question

在Django doc,

select_related()“跟随”外键关系，在执行查询时选择其他相关对象数据。

我的理解是，对于外键关系，使用select_related；对于M2M关系，请使用prefetch_related。这是正确的吗？

Answer 1

你的理解大体上是正确的。如果要选择的对象是单个对象，则使用select_related，因此使用OneTooneField或ForeignKey。当您要获取一个“集合”时，您可以使用prefetch_related，因此manytomanyfield如您所述，或者将foreignkey反向。为了澄清“reverseforeignkeys”是什么意思，这里有一个示例：

class ModelA(models.Model):
    pass

class ModelB(models.Model):
    a = ForeignKey(ModelA)

ModelB.objects.select_related('a').all() # Forward ForeignKey relationship
ModelA.objects.prefetch_related('modelb_set').all() # Reverse ForeignKey relationship

不同的是，select_related执行SQL联接，因此从SQL Server将结果作为表的一部分返回。另一方面，prefetch_related执行另一个查询，因此减少了原始对象中的冗余列（上例中为modela)。对于可以使用select_related的任何内容，都可以使用prefetch_related。

折衷之处是prefetch_related必须创建一个ID列表并将其发送回服务器，这可能需要一段时间。我不确定是否有一个很好的方法在一个事务中这样做，但我的理解是Django总是发送一个列表，并说SELECT...在那里pk（...,...）基本上是。在这种情况下，如果预取的数据是稀疏的（比方说链接到人的地址的美国状态对象），这可能是非常好的，但是，如果它更接近于一对一，这可能会浪费大量的通信。如果有疑问，两个都试试，看看哪一个表现更好。

上面讨论的所有内容基本上都是关于与数据库的通信。然而，在Python方面，prefetch_related有一个额外的好处，即使用一个对象来表示数据库中的每个对象。使用select_related将在Python中为每个“父”对象创建重复的对象。由于Python中的对象具有相当大的内存开销，这也是一个考虑因素。