在数据库有外键的时候，使用 select_related() 和 prefetch_related() 可以很好的减少数据库请求的次数，从而提高性能。本文通过一个简单的例子详解这两个函数的作用。虽然QuerySet的文档中已经详细说明了，但本文试图从QuerySet触发的SQL语句来分析工作方式，从而进一步了解Django具体的运作方式。

1. 实例的背景说明

假定一个个人信息系统，需要记录系统中各个人的故乡、居住地、以及到过的城市。数据库设计如下：

Models.py 内容如下：

  1. from django.db import models
  2.  
  3. class Province(models.Model):
  4.     name = models.CharField(max_length=10)
  5.     def __unicode__(self):
  6.         return self.name
  7.  
  8. class City(models.Model):
  9.     name = models.CharField(max_length=5)
  10.     province = models.ForeignKey(Province)
  11.     def __unicode__(self):
  12.         return self.name
  13.  
  14. class Person(models.Model):
  15.     firstname  = models.CharField(max_length=10)
  16.     lastname   = models.CharField(max_length=10)
  17.     visitation = models.ManyToManyField(City, related_name = "visitor")
  18.     hometown   = models.ForeignKey(City, related_name = "birth")
  19.     living     = models.ForeignKey(City, related_name = "citizen")
  20.     def __unicode__(self):
  21.         return self.firstname + self.lastname

注1：创建的app名为“QSOptimize”

注2：为了简化起见，`qsoptimize_province` 表中只有2条数据：湖北省和广东省，`qsoptimize_city`表中只有三条数据：武汉市、十堰市和广州市

2. select_related()

对于一对一字段（OneToOneField）和外键字段（ForeignKey），可以使用select_related 来对QuerySet进行优化

作用和方法

在对QuerySet使用select_related()函数后，Django会获取相应外键对应的对象，从而在之后需要的时候不必再查询数据库了。以上例说明，如果我们需要打印数据库中的所有市及其所属省份，最直接的做法是：

  1. >>> citys = City.objects.all()
  2. >>> for c in citys:
  3. ...   print c.province
  4. ...

这样会导致线性的SQL查询，如果对象数量n太多，每个对象中有k个外键字段的话，就会导致n*k+1次SQL查询。在本例中，因为有3个city对象就导致了4次SQL查询：

  1. SELECT `QSOptimize_city`.`id`, `QSOptimize_city`.`name`, `QSOptimize_city`.`province_id`
  2. FROM `QSOptimize_city`
  3.  
  4. SELECT `QSOptimize_province`.`id`, `QSOptimize_province`.`name`
  5. FROM `QSOptimize_province`
  6. WHERE `QSOptimize_province`.`id` = 1 ;
  7.  
  8. SELECT `QSOptimize_province`.`id`, `QSOptimize_province`.`name`
  9. FROM `QSOptimize_province`
  10. WHERE `QSOptimize_province`.`id` = 2 ;
  11.  
  12. SELECT `QSOptimize_province`.`id`, `QSOptimize_province`.`name`
  13. FROM `QSOptimize_province`
  14. WHERE `QSOptimize_province`.`id` = 1 ;

如果我们使用select_related()函数：

  1. >>> citys = City.objects.select_related().all()
  2. >>> for c in citys:
  3. ...   print c.province
  4. ...

就只有一次SQL查询，显然大大减少了SQL查询的次数：

  1. SELECT `QSOptimize_city`.`id`, `QSOptimize_city`.`name`,
  2. `QSOptimize_city`.`province_id`, `QSOptimize_province`.`id`, `QSOptimize_province`.`name`
  3. FROM`QSOptimize_city`
  4. INNER JOIN `QSOptimize_province` ON (`QSOptimize_city`.`province_id` = `QSOptimize_province`.`id`) ;

这里我们可以看到，Django使用了INNER JOIN来获得省份的信息。顺便一提这条SQL查询得到的结果如下：

+----+-----------+-------------+----+-----------+
| id | name      | province_id | id | name      |
+----+-----------+-------------+----+-----------+
|  1 | 武汉市    |           1 |  1 | 湖北省    |
|  2 | 广州市    |           2 |  2 | 广东省    |
|  3 | 十堰市    |           1 |  1 | 湖北省    |
+----+-----------+-------------+----+-----------+
3 rows in set (0.00 sec)

使用方法

函数支持如下三种用法：
*fields 参数

select_related() 接受可变长参数，每个参数是需要获取的外键（父表的内容）的字段名，以及外键的外键的字段名、外键的外键的外键…。若要选择外键的外键需要使用两个下划线“__”来连接。

例如我们要获得张三的现居省份，可以用如下方式：

  1. >>> zhangs = Person.objects.select_related('living__province').get(firstname=u"张",lastname=u"三")
  2. >>> zhangs.living.province

触发的SQL查询如下：

  1. SELECT `QSOptimize_person`.`id`, `QSOptimize_person`.`firstname`,
  2. `QSOptimize_person`.`lastname`, `QSOptimize_person`.`hometown_id`, `QSOptimize_person`.`living_id`,
  3. `QSOptimize_city`.`id`, `QSOptimize_city`.`name`, `QSOptimize_city`.`province_id`, `QSOptimize_province`.`id`,
  4. `QSOptimize_province`.`name`
  5. FROM `QSOptimize_person`
  6. INNER JOIN `QSOptimize_city` ON (`QSOptimize_person`.`living_id` = `QSOptimize_city`.`id`)
  7. INNER JOIN `QSOptimize_province` ON (`QSOptimize_city`.`province_id` = `QSOptimize_province`.`id`)
  8. WHERE (`QSOptimize_person`.`lastname` = '三'  AND `QSOptimize_person`.`firstname` = '张' );

可以看到，Django使用了2次 INNER JOIN 来完成请求，获得了city表和province表的内容并添加到结果表的相应列，这样在调用 zhangs.living的时候也不必再次进行SQL查询。

  1. +----+-----------+----------+-------------+-----------+----+-----------+-------------+----+-----------+
  2. | id | firstname | lastname | hometown_id | living_id | id | name      | province_id | id | name      |
  3. +----+-----------+----------+-------------+-----------+----+-----------+-------------+----+-----------+
  4. |  1 | 张        | 三       |           3 |         1 |  1 | 武汉市    |   1         |  1 | 湖北省    |
  5. +----+-----------+----------+-------------+-----------+----+-----------+-------------+----+-----------+
  6. 1 row in set (0.00 sec)

然而，未指定的外键则不会被添加到结果中。这时候如果需要获取张三的故乡就会进行SQL查询了：

  1. >>> zhangs.hometown.province
  2.  
  3. SELECT `QSOptimize_city`.`id`, `QSOptimize_city`.`name`,
  4. `QSOptimize_city`.`province_id`
  5. FROM `QSOptimize_city`
  6. WHERE `QSOptimize_city`.`id` = 3 ;
  7.  
  8. SELECT `QSOptimize_province`.`id`, `QSOptimize_province`.`name`
  9. FROM `QSOptimize_province`
  10. WHERE `QSOptimize_province`.`id` = 1

同时，如果不指定外键，就会进行两次查询。如果深度更深，查询的次数更多。

值得一提的是，从Django 1.7开始，select_related()函数的作用方式改变了。在本例中，如果要同时获得张三的故乡和现居地的省份，在1.7以前你只能这样做：

  1. >>> zhangs = Person.objects.select_related('hometown__province','living__province').get(firstname=u"张",lastname=u"三")
  2. >>> zhangs.hometown.province
  3. >>> zhangs.living.province

但是1.7及以上版本，你可以像和queryset的其他函数一样进行链式操作：

  1. >>> zhangs = Person.objects.select_related('hometown__province').select_related('living__province').get(firstname=u"张",lastname=u"三")
  2. >>> zhangs.hometown.province
  3. >>> zhangs.living.province

如果你在1.7以下版本这样做了，你只会获得最后一个操作的结果，在本例中就是只有现居地而没有故乡。在你打印故乡省份的时候就会造成两次SQL查询。

depth 参数

select_related() 接受depth参数，depth参数可以确定select_related的深度。Django会递归遍历指定深度内的所有的OneToOneField和ForeignKey。以本例说明：

  1. >>> zhangs = Person.objects.select_related(depth = d)

d=1  相当于 select_related(‘hometown’,'living’)

d=2  相当于 select_related(‘hometown__province’,'living__province’)

无参数

select_related() 也可以不加参数，这样表示要求Django尽可能深的select_related。例如：zhangs = Person.objects.select_related().get(firstname=u”张”,lastname=u”三”)。但要注意两点：

1.Django本身内置一个上限，对于特别复杂的表关系，Django可能在你不知道的某处跳出递归，从而与你想的做法不一样。具体限制是怎么工作的我表示不清楚。
    2.Django并不知道你实际要用的字段有哪些，所以会把所有的字段都抓进来，从而会造成不必要的浪费而影响性能。

小结

1.select_related主要针一对一和多对一关系进行优化。
2.select_related使用SQL的JOIN语句进行优化，通过减少SQL查询的次数来进行优化、提高性能。
3.可以通过可变长参数指定需要select_related的字段名。也可以通过使用双下划线“__”连接字段名来实现指定的递归查询。没有指定的字段不会缓存，没有指定的深度不会缓存，如果要访问的话Django会再次进行SQL查询。
4.也可以通过depth参数指定递归的深度，Django会自动缓存指定深度内所有的字段。如果要访问指定深度外的字段，Django会再次进行SQL查询。
5.也接受无参数的调用，Django会尽可能深的递归查询所有的字段。但注意有Django递归的限制和性能的浪费。
6.Django >= 1.7，链式调用的select_related相当于使用可变长参数。Django < 1.7，链式调用会导致前边的select_related失效，只保留最后一个。

3. prefetch_related()

对于多对多字段（ManyToManyField）和一对多字段，可以使用prefetch_related()来进行优化。或许你会说，没有一个叫OneToManyField的东西啊。实际上
，ForeignKey就是一个多对一的字段，而被ForeignKey关联的字段就是一对多字段了。

作用和方法

prefetch_related()和select_related()的设计目的很相似，都是为了减少SQL查询的数量，但是实现的方式不一样。后者是通过JOIN语句，在SQL查询内解决问题。但是对于多对多关系，使用SQL语句解决就显得有些不太明智，因为JOIN得到的表将会很长，会导致SQL语句运行时间的增加和内存占用的增加。若有n个对象，每个对象的多对多字段对应Mi条，就会生成Σ(n)Mi

行的结果表。prefetch_related()的解决方法是，分别查询每个表，然后用Python处理他们之间的关系。继续以上边的例子进行说明，如果我们要获得张三所有去过的城市，使用prefetch_related()应该是这么做：

  1. >>> zhangs = Person.objects.prefetch_related('visitation').get(firstname=u"张",lastname=u"三")
  2. >>> for city in zhangs.visitation.all() :
  3. ...   print city
  4. ...

上述代码触发的SQL查询如下：

  1. SELECT `QSOptimize_person`.`id`, `QSOptimize_person`.`firstname`,
  2. `QSOptimize_person`.`lastname`, `QSOptimize_person`.`hometown_id`, `QSOptimize_person`.`living_id`
  3. FROM `QSOptimize_person`
  4. WHERE (`QSOptimize_person`.`lastname` = '三'  AND `QSOptimize_person`.`firstname` = '张');
  5.  
  6. SELECT (`QSOptimize_person_visitation`.`person_id`) AS `_prefetch_related_val`, `QSOptimize_city`.`id`,
  7. `QSOptimize_city`.`name`, `QSOptimize_city`.`province_id`
  8. FROM `QSOptimize_city`
  9. INNER JOIN `QSOptimize_person_visitation` ON (`QSOptimize_city`.`id` = `QSOptimize_person_visitation`.`city_id`)
  10. WHERE `QSOptimize_person_visitation`.`person_id` IN (1);

第一条SQL查询仅仅是获取张三的Person对象，第二条比较关键，它选取关系表`QSOptimize_person_visitation`中`person_id`为张三的行，然后和`city`表内联（INNER JOIN 也叫等值连接）得到结果表。

  1. +----+-----------+----------+-------------+-----------+
  2. | id | firstname | lastname | hometown_id | living_id |
  3. +----+-----------+----------+-------------+-----------+
  4. |  1 | 张        | 三       |           3 |         1 |
  5. +----+-----------+----------+-------------+-----------+
  6. 1 row in set (0.00 sec)
  7.  
  8. +-----------------------+----+-----------+-------------+
  9. | _prefetch_related_val | id | name      | province_id |
  10. +-----------------------+----+-----------+-------------+
  11. |                     1 |  1 | 武汉市    |           1 |
  12. |                     1 |  2 | 广州市    |           2 |
  13. |                     1 |  3 | 十堰市    |           1 |
  14. +-----------------------+----+-----------+-------------+
  15. 3 rows in set (0.00 sec)

显然张三武汉、广州、十堰都去过。

又或者，我们要获得湖北的所有城市名，可以这样：

  1. >>> hb = Province.objects.prefetch_related('city_set').get(name__iexact=u"湖北省")
  2. >>> for city in hb.city_set.all():
  3. ...   city.name
  4. ...

触发的SQL查询：

  1. SELECT `QSOptimize_province`.`id`, `QSOptimize_province`.`name`
  2. FROM `QSOptimize_province`
  3. WHERE `QSOptimize_province`.`name` LIKE '湖北省' ;
  4.  
  5. SELECT `QSOptimize_city`.`id`, `QSOptimize_city`.`name`, `QSOptimize_city`.`province_id`
  6. FROM `QSOptimize_city`
  7. WHERE `QSOptimize_city`.`province_id` IN (1);

得到的表：

  1. +----+-----------+
  2. | id | name      |
  3. +----+-----------+
  4. |  1 | 湖北省    |
  5. +----+-----------+
  6. 1 row in set (0.00 sec)
  8. +----+-----------+-------------+
  9. | id | name      | province_id |
  10. +----+-----------+-------------+
  11. |  1 | 武汉市    |           1 |
  12. |  3 | 十堰市    |           1 |
  13. +----+-----------+-------------+
  14. 2 rows in set (0.00 sec)

我们可以看见，prefetch使用的是 IN 语句实现的。这样，在QuerySet中的对象数量过多的时候，根据数据库特性的不同有可能造成性能问题。

使用方法

*lookups 参数

prefetch_related()在Django < 1.7 只有这一种用法。和select_related()一样，prefetch_related()也支持深度查询，例如要获得所有姓张的人去过的省：

  1. >>> zhangs = Person.objects.prefetch_related('visitation__province').filter(firstname__iexact=u'张')
  2. >>> for i in zhangs:
  3. ...   for city in i.visitation.all():
  4. ...     print city.province
  5. ...

触发的SQL：

  1. SELECT `QSOptimize_person`.`id`, `QSOptimize_person`.`firstname`,
  2. `QSOptimize_person`.`lastname`, `QSOptimize_person`.`hometown_id`, `QSOptimize_person`.`living_id`
  3. FROM `QSOptimize_person`
  4. WHERE `QSOptimize_person`.`firstname` LIKE '张' ;
  5.  
  6. SELECT (`QSOptimize_person_visitation`.`person_id`) AS `_prefetch_related_val`, `QSOptimize_city`.`id`,
  7. `QSOptimize_city`.`name`, `QSOptimize_city`.`province_id` FROM `QSOptimize_city`
  8. INNER JOIN `QSOptimize_person_visitation` ON (`QSOptimize_city`.`id` = `QSOptimize_person_visitation`.`city_id`)
  9. WHERE `QSOptimize_person_visitation`.`person_id` IN (1, 4);
  10.  
  11. SELECT `QSOptimize_province`.`id`, `QSOptimize_province`.`name`
  12. FROM `QSOptimize_province`
  13. WHERE `QSOptimize_province`.`id` IN (1, 2);

获得的结果：

  1. +----+-----------+----------+-------------+-----------+
  2. | id | firstname | lastname | hometown_id | living_id |
  3. +----+-----------+----------+-------------+-----------+
  4. |  1 | 张        | 三       |           3 |         1 |
  5. |  4 | 张        | 六       |           2 |         2 |
  6. +----+-----------+----------+-------------+-----------+
  7. 2 rows in set (0.00 sec)
  9. +-----------------------+----+-----------+-------------+
  10. | _prefetch_related_val | id | name      | province_id |
  11. +-----------------------+----+-----------+-------------+
  12. |                     1 |  1 | 武汉市    |           1 |
  13. |                     1 |  2 | 广州市    |           2 |
  14. |                     4 |  2 | 广州市    |           2 |
  15. |                     1 |  3 | 十堰市    |           1 |
  16. +-----------------------+----+-----------+-------------+
  17. 4 rows in set (0.00 sec)
  19. +----+-----------+
  20. | id | name      |
  21. +----+-----------+
  22. |  1 | 湖北省    |
  23. |  2 | 广东省    |
  24. +----+-----------+
  25. 2 rows in set (0.00 sec)

值得一提的是，链式prefetch_related会将这些查询添加起来，就像1.7中的select_related那样。

要注意的是，在使用QuerySet的时候，一旦在链式操作中改变了数据库请求，之前用prefetch_related缓存的数据将会被忽略掉。这会导致Django重新请求数据库来获得相应的数据，从而造成性能问题。这里提到的改变数据库请求指各种filter()、exclude()等等最终会改变SQL代码的操作。而all()并不会改变最终的数据库请求，因此是不会导致重新请求数据库的。

举个例子，要获取所有人访问过的城市中带有“市”字的城市，这样做会导致大量的SQL查询：

  1. plist =Person.objects.prefetch_related('visitation')
  2. [p.visitation.filter(name__icontains=u"市")for p in plist]

因为数据库中有4人，导致了2+4次SQL查询：

  1. SELECT `QSOptimize_person`.`id`, `QSOptimize_person`.`firstname`, `QSOptimize_person`.`lastname`,
  2. `QSOptimize_person`.`hometown_id`, `QSOptimize_person`.`living_id`
  3. FROM `QSOptimize_person`;
  4.  
  5. SELECT (`QSOptimize_person_visitation`.`person_id`) AS `_prefetch_related_val`, `QSOptimize_city`.`id`,
  6. `QSOptimize_city`.`name`, `QSOptimize_city`.`province_id`
  7. FROM `QSOptimize_city`
  8. INNER JOIN `QSOptimize_person_visitation` ON (`QSOptimize_city`.`id` = `QSOptimize_person_visitation`.`city_id`)
  9. WHERE `QSOptimize_person_visitation`.`person_id` IN (1, 2, 3, 4);
  10.  
  11. SELECT `QSOptimize_city`.`id`, `QSOptimize_city`.`name`, `QSOptimize_city`.`province_id`
  12. FROM `QSOptimize_city`
  13. INNER JOIN `QSOptimize_person_visitation` ON (`QSOptimize_city`.`id` = `QSOptimize_person_visitation`.`city_id`)
  14. WHERE(`QSOptimize_person_visitation`.`person_id` = 1  AND `QSOptimize_city`.`name` LIKE '%市%' );
  15.  
  16. SELECT `QSOptimize_city`.`id`, `QSOptimize_city`.`name`, `QSOptimize_city`.`province_id`
  17. FROM `QSOptimize_city`
  18. INNER JOIN `QSOptimize_person_visitation` ON (`QSOptimize_city`.`id` = `QSOptimize_person_visitation`.`city_id`)
  19. WHERE (`QSOptimize_person_visitation`.`person_id` = 2  AND `QSOptimize_city`.`name` LIKE '%市%' );
  20.  
  21. SELECT `QSOptimize_city`.`id`, `QSOptimize_city`.`name`, `QSOptimize_city`.`province_id`
  22. FROM `QSOptimize_city`
  23. INNER JOIN `QSOptimize_person_visitation` ON (`QSOptimize_city`.`id` = `QSOptimize_person_visitation`.`city_id`)
  24. WHERE (`QSOptimize_person_visitation`.`person_id` = 3  AND `QSOptimize_city`.`name` LIKE '%市%' );
  25.  
  26. SELECT `QSOptimize_city`.`id`, `QSOptimize_city`.`name`, `QSOptimize_city`.`province_id`
  27. FROM `QSOptimize_city`
  28. INNER JOIN `QSOptimize_person_visitation` ON (`QSOptimize_city`.`id` = `QSOptimize_person_visitation`.`city_id`)
  29. WHERE (`QSOptimize_person_visitation`.`person_id` = 4  AND `QSOptimize_city`.`name` LIKE '%市%' );

众所周知，QuerySet是lazy的，要用的时候才会去访问数据库。运行到第二行Python代码时，for循环将plist看做iterator，这会触发数据库查询。最初的两次SQL查询就是prefetch_related导致的。

虽然已经查询结果中包含所有所需的city的信息，但因为在循环体中对Person.visitation进行了filter操作，这显然改变了数据库请求。因此这些操作会忽略掉之前缓存到的数据，重新进行SQL查询。

但是如果有这样的需求了应该怎么办呢？在Django >= 1.7，可以通过下一节的Prefetch对象来实现，如果你的环境是Django < 1.7，可以在Python中完成这部分操作。

  1. plist = Person.objects.prefetch_related('visitation')
  2. [[city for city in p.visitation.all() if u"市" in city.name] for p in plist]

Prefetch对象

在Django >= 1.7，可以用Prefetch对象来控制prefetch_related函数的行为。

1.一个Prefetch对象只能指定一项prefetch操作。
2.Prefetch对象对字段指定的方式和prefetch_related中的参数相同，都是通过双下划线连接的字段名完成的。
3.可以通过 queryset 参数手动指定prefetch使用的QuerySet。
4.可以通过 to_attr 参数指定prefetch到的属性名。
5.Prefetch对象和字符串形式指定的lookups参数可以混用。

4. 最佳实践

1.prefetch_related主要针一对多和多对多关系进行优化。
2.prefetch_related通过分别获取各个表的内容，然后用Python处理他们之间的关系来进行优化。
3.可以通过可变长参数指定需要select_related的字段名。指定方式和特征与select_related是相同的。
4.在Django >= 1.7可以通过Prefetch对象来实现复杂查询，但低版本的Django好像只能自己实现。
5.作为prefetch_related的参数，Prefetch对象和字符串可以混用。
6.prefetch_related的链式调用会将对应的prefetch添加进去，而非替换，似乎没有基于不同版本上区别。
7.可以通过传入None来清空之前的prefetch_related。

选择哪个函数

如果我们想要获得所有家乡是湖北的人，最无脑的做法是先获得湖北省，再获得湖北的所有城市，最后获得故乡是这个城市的人。就像这样：

  1. >>> hb = Province.objects.get(name__iexact=u"湖北省")
  2. >>> people = []
  3. >>> for city in hb.city_set.all():
  4. ...   people.extend(city.birth.all())
  5. ...
显然这不是一个明智的选择，因为这样做会导致1+（湖北省城市数）次SQL查询。反正是个反例，导致的查询和获得掉结果就不列出来了。

prefetch_related() 或许是一个好的解决方法，让我们来看看。

  1. >>> hb = Province.objects.prefetch_related("city_set__birth").objects.get(name__iexact=u"湖北省")
  2. >>> people = []
  3. >>> for city in hb.city_set.all():
  4. ...   people.extend(city.birth.all())
  5. ...

因为是一个深度为2的prefetch，所以会导致3次SQL查询：

  1. SELECT `QSOptimize_province`.`id`, `QSOptimize_province`.`name`
  2. FROM `QSOptimize_province`
  3. WHERE `QSOptimize_province`.`name` LIKE '湖北省' ;
  4.  
  5. SELECT `QSOptimize_city`.`id`, `QSOptimize_city`.`name`, `QSOptimize_city`.`province_id`
  6. FROM `QSOptimize_city`
  7. WHERE `QSOptimize_city`.`province_id` IN (1);
  8.  
  9. SELECT `QSOptimize_person`.`id`, `QSOptimize_person`.`firstname`, `QSOptimize_person`.`lastname`,
  10. `QSOptimize_person`.`hometown_id`, `QSOptimize_person`.`living_id`
  11. FROM `QSOptimize_person`
  12. WHERE `QSOptimize_person`.`hometown_id` IN (1, 3);

嗯…看上去不错，但是3次查询么？倒过来查询可能会更简单？

  1. >>> people = list(Person.objects.select_related("hometown__province").filter(hometown__province__name__iexact=u"湖北省"))
  1. SELECT `QSOptimize_person`.`id`, `QSOptimize_person`.`firstname`, `QSOptimize_person`.`lastname`,
  2. `QSOptimize_person`.`hometown_id`, `QSOptimize_person`.`living_id`, `QSOptimize_city`.`id`,
  3. `QSOptimize_city`.`name`, `QSOptimize_city`.`province_id`, `QSOptimize_province`.`id`, `QSOptimize_province`.`name`
  4. FROM `QSOptimize_person`
  5. INNER JOIN `QSOptimize_city` ON (`QSOptimize_person`.`hometown_id` = `QSOptimize_city`.`id`)
  6. INNER JOIN `QSOptimize_province` ON (`QSOptimize_city`.`province_id` = `QSOptimize_province`.`id`)
  7. WHERE `QSOptimize_province`.`name` LIKE '湖北省';
  1. +----+-----------+----------+-------------+-----------+----+--------+-------------+----+--------+
  2. | id | firstname | lastname | hometown_id | living_id | id | name   | province_id | id | name   |
  3. +----+-----------+----------+-------------+-----------+----+--------+-------------+----+--------+
  4. |  1 | 张        | 三       |           3 |         1 |  3 | 十堰市 |           1 |  1 | 湖北省 |
  5. |  2 | 李        | 四       |           1 |         3 |  1 | 武汉市 |           1 |  1 | 湖北省 |
  6. |  3 | 王        | 麻子     |           3 |         2 |  3 | 十堰市 |           1 |  1 | 湖北省 |
  7. +----+-----------+----------+-------------+-----------+----+--------+-------------+----+--------+
  8. 3 rows in set (0.00 sec)
完全没问题。不仅SQL查询的数量减少了，python程序上也精简了。
select_related()的效率要高于prefetch_related()。因此，最好在能用select_related()的地方尽量使用它，也就是说，对于ForeignKey字段，避免使用prefetch_related()。

对于同一个QuerySet，你可以同时使用这两个函数。在我们一直使用的例子上加一个model：Order （订单）

  1. class Order(models.Model):
  2.     customer   = models.ForeignKey(Person)
  3.     orderinfo  = models.CharField(max_length=50)
  4.     time       = models.DateTimeField(auto_now_add = True)
  5.     def __unicode__(self):
  6.         return self.orderinfo

如果我们拿到了一个订单的id 我们要知道这个订单的客户去过的省份。因为有ManyToManyField显然必须要用prefetch_related()。如果只用prefetch_related()会怎样呢？

  1. >>> plist = Order.objects.prefetch_related('customer__visitation__province').get(id=1)
  2. >>> for city in plist.customer.visitation.all():
  3. ...   print city.province.name
  4. ...

显然，关系到了4个表：Order、Person、City、Province，根据prefetch_related()的特性就得有4次SQL查询

  1. SELECT `QSOptimize_order`.`id`, `QSOptimize_order`.`customer_id`, `QSOptimize_order`.`orderinfo`, `QSOptimize_order`.`time`
  2. FROM `QSOptimize_order`
  3. WHERE `QSOptimize_order`.`id` = 1 ;
  4.  
  5. SELECT `QSOptimize_person`.`id`, `QSOptimize_person`.`firstname`, `QSOptimize_person`.`lastname`, `QSOptimize_person`.`hometown_id`, `QSOptimize_person`.`living_id`
  6. FROM `QSOptimize_person`
  7. WHERE `QSOptimize_person`.`id` IN (1);
  8.  
  9. SELECT (`QSOptimize_person_visitation`.`person_id`) AS `_prefetch_related_val`, `QSOptimize_city`.`id`,
  10. `QSOptimize_city`.`name`, `QSOptimize_city`.`province_id`
  11. FROM `QSOptimize_city`
  12. INNER JOIN `QSOptimize_person_visitation` ON (`QSOptimize_city`.`id` = `QSOptimize_person_visitation`.`city_id`)
  13. WHERE `QSOptimize_person_visitation`.`person_id` IN (1);
  14.  
  15. SELECT `QSOptimize_province`.`id`, `QSOptimize_province`.`name`
  16. FROM `QSOptimize_province`
  17. WHERE `QSOptimize_province`.`id` IN (1, 2);
  1. +----+-------------+---------------+---------------------+
  2. | id | customer_id | orderinfo     | time                |
  3. +----+-------------+---------------+---------------------+
  4. |  1 |           1 | Info of Order | 2014-08-10 17:05:48 |
  5. +----+-------------+---------------+---------------------+
  6. 1 row in set (0.00 sec)
  8. +----+-----------+----------+-------------+-----------+
  9. | id | firstname | lastname | hometown_id | living_id |
  10. +----+-----------+----------+-------------+-----------+
  11. |  1 | 张        | 三       |           3 |         1 |
  12. +----+-----------+----------+-------------+-----------+
  13. 1 row in set (0.00 sec)
  15. +-----------------------+----+--------+-------------+
  16. | _prefetch_related_val | id | name   | province_id |
  17. +-----------------------+----+--------+-------------+
  18. |                     1 |  1 | 武汉市 |           1 |
  19. |                     1 |  2 | 广州市 |           2 |
  20. |                     1 |  3 | 十堰市 |           1 |
  21. +-----------------------+----+--------+-------------+
  22. 3 rows in set (0.00 sec)
  24. +----+--------+
  25. | id | name   |
  26. +----+--------+
  27. |  1 | 湖北省 |
  28. |  2 | 广东省 |
  29. +----+--------+
  30. 2 rows in set (0.00 sec)

更好的办法是先调用一次select_related()再调用prefetch_related()，最后再select_related()后面的表

  1. >>> plist = Order.objects.select_related('customer').prefetch_related('customer__visitation__province').get(id=1)
  2. >>> for city in plist.customer.visitation.all():
  3. ...   print city.province.name
  4. ...

这样只会有3次SQL查询，Django会先做select_related，之后prefetch_related的时候会利用之前缓存的数据，从而避免了1次额外的SQL查询：

  1. SELECT `QSOptimize_order`.`id`, `QSOptimize_order`.`customer_id`, `QSOptimize_order`.`orderinfo`,
  2. `QSOptimize_order`.`time`, `QSOptimize_person`.`id`, `QSOptimize_person`.`firstname`,
  3. `QSOptimize_person`.`lastname`, `QSOptimize_person`.`hometown_id`, `QSOptimize_person`.`living_id`
  4. FROM `QSOptimize_order`
  5. INNER JOIN `QSOptimize_person` ON (`QSOptimize_order`.`customer_id` = `QSOptimize_person`.`id`)
  6. WHERE `QSOptimize_order`.`id` = 1 ;
  7.  
  8. SELECT (`QSOptimize_person_visitation`.`person_id`) AS `_prefetch_related_val`, `QSOptimize_city`.`id`,
  9. `QSOptimize_city`.`name`, `QSOptimize_city`.`province_id`
  10. FROM `QSOptimize_city`
  11. INNER JOIN `QSOptimize_person_visitation` ON (`QSOptimize_city`.`id` = `QSOptimize_person_visitation`.`city_id`)
  12. WHERE `QSOptimize_person_visitation`.`person_id` IN (1);
  13.  
  14. SELECT `QSOptimize_province`.`id`, `QSOptimize_province`.`name`
  15. FROM `QSOptimize_province`
  16. WHERE `QSOptimize_province`.`id` IN (1, 2);
  1. +----+-------------+---------------+---------------------+----+-----------+----------+-------------+-----------+
  2. | id | customer_id | orderinfo     | time                | id | firstname | lastname | hometown_id | living_id |
  3. +----+-------------+---------------+---------------------+----+-----------+----------+-------------+-----------+
  4. |  1 |           1 | Info of Order | 2014-08-10 17:05:48 |  1 | 张        | 三       |           3 |         1 |
  5. +----+-------------+---------------+---------------------+----+-----------+----------+-------------+-----------+
  6. 1 row in set (0.00 sec)
  8. +-----------------------+----+--------+-------------+
  9. | _prefetch_related_val | id | name   | province_id |
  10. +-----------------------+----+--------+-------------+
  11. |                     1 |  1 | 武汉市 |           1 |
  12. |                     1 |  2 | 广州市 |           2 |
  13. |                     1 |  3 | 十堰市 |           1 |
  14. +-----------------------+----+--------+-------------+
  15. 3 rows in set (0.00 sec)
  17. +----+--------+
  18. | id | name   |
  19. +----+--------+
  20. |  1 | 湖北省 |
  21. |  2 | 广东省 |
  22. +----+--------+
  23. 2 rows in set (0.00 sec)

值得注意的是，可以在调用prefetch_related之前调用select_related，并且Django会按照你想的去做：先select_related，然后利用缓存到的数据prefetch_related。然而一旦prefetch_related已经调用，select_related将不起作用。

小结

  1. 因为select_related()总是在单次SQL查询中解决问题，而prefetch_related()会对每个相关表进行SQL查询，因此select_related()的效率通常比后者高。
  2. 鉴于第一条，尽可能的用select_related()解决问题。只有在select_related()不能解决问题的时候再去想prefetch_related()。
  3. 你可以在一个QuerySet中同时使用select_related()和prefetch_related()，从而减少SQL查询的次数。
  4. 只有prefetch_related()之前的select_related()是有效的，之后的将会被无视掉。
  1. 原文：https://blog.csdn.net/secretx/article/details/43964607

Django的select_related 和 prefetch_related 函数优化查询的更多相关文章

  1. 这个贴子的内容值得好好学习--实例详解Django的 select_related 和 prefetch_related 函数对 QuerySet 查询的优化

    感觉要DJANGO用得好,ORM必须要学好,不管理是内置的,还是第三方的ORM. 最最后还是要到SQL.....:( 这一关,慢慢练啦.. 实例详解Django的 select_related 和 p ...

  2. Django的 select_related 和 prefetch_related 函数对 QuerySet 查询的优化（二）

    3. prefetch_related() 对于多对多字段(ManyToManyField)和一对多字段,可以使用prefetch_related()来进行优化.或许你会说,没有一个叫OneToMan ...

  3. Django的 select_related 和 prefetch_related 函数对 QuerySet 查询的优化（一）

    在数据库有外键的时候,使用 select_related() 和 prefetch_related() 可以很好的减少数据库请求的次数,从而提高性能.本文通过一个简单的例子详解这两个函数的作用.虽然Q ...

  4. 转载 ：实例详解Django的 select_related 和 prefetch_related 函数对 QuerySet 查询的优化（一）

    在数据库有外键的时候,使用 select_related() 和 prefetch_related() 可以很好的减少数据库请求的次数,从而提高性能.本文通过一个简单的例子详解这两个函数的作用.虽然Q ...

  5. 实例具体解释Django的 select_related 和 prefetch_related 函数对 QuerySet 查询的优化（二）

    这是本系列的第二篇,内容是 prefetch_related() 函数的用途.实现途径.以及用法. 本系列的第一篇在这里 第三篇在这里 3. prefetch_related() 对于多对多字段(Ma ...

  6. 详解Django的 select_related 和 prefetch_related 函数对 QuerySet 查询的优化

    在数据库有外键的时候,使用 select_related() 和 prefetch_related() 可以很好的减少数据库请求的次数,从而提高性能.本文通过一个简单的例子详解这两个函数的作用. 1. ...

  7. Django的 select_related 和 prefetch_related 函数对 QuerySet 查询的优化

    引言 在数据库存在外键的其情况下,使用select_related()和prefetch_related()很大程度上减少对数据库的请求次数以提高性能 1.实例准备 模型: from django.d ...

  8. 转 实例具体解释DJANGO的 SELECT_RELATED 和 PREFETCH_RELATED 函数对 QUERYSET 查询的优化（二）

    https://blog.csdn.net/cugbabybear/article/details/38342793 这是本系列的第二篇,内容是 prefetch_related() 函数的用途.实现 ...

  9. Django的 select_related 和 prefetch_related 函数对 QuerySet 查询的优化（三）

    4.一些实例 如果我们想要获得所有家乡是湖北的人,最无脑的做法是先获得湖北省,再获得湖北的所有城市,最后获得故乡是这个城市的人.就像这样: 1 2 3 4 5 >>> hb = Pr ...

随机推荐

  1. 20165308《Java程序设计》第7周学习总结

    20165308<Java程序设计>第7周学习总结 教材学习内容总结 第十一章:JDBC与MySQL数据库 MySQL数据库管理系统 启动MySQL数据库服务器 MySQL客户端管理工具 ...

  2. 【转】Android AlertDialog自定义布局

    原文网址:https://blog.csdn.net/u010694658/article/details/53022294 由于开发中经常使用弹框,然而系统自带的弹框太局限,也不太美观,经常不能满足 ...

  3. react-router v4 实现路由拦截的一种思路（待验证）

    出处:https://segmentfault.com/q/1010000010905474

  4. pandas读取MySql/SqlServer数据 (转)

    在 Anacondas环境中,conda install pymssql ,一直报包冲突,所以采用先在 https://www.lfd.uci.edu/~gohlke/pythonlibs/#nump ...

  5. 【Spark Java API】broadcast、accumulator

    转载自:http://www.jianshu.com/p/082ef79c63c1 broadcast 官方文档描述: Broadcast a read-only variable to the cl ...

  6. class path resource [spring/ApplicationContext-springmvc.xml] cannot be opened because it does not exist

    配置如下: <init-param>   <param-name>contextConfigLocation</param-name>   <param-va ...

  7. delphi读取xml文件

    功能: 根据省份更新地市信息 -------------------------------------------------------------------------------} proc ...

  8. 一文全解：利用谷歌深度学习框架Tensorflow识别手写数字图片（初学者篇）

    笔记整理者:王小草 笔记整理时间2017年2月24日 原文地址 http://blog.csdn.net/sinat_33761963/article/details/56837466?fps=1&a ...

  9. Azure Application Gateway (5) Application Gateway SSL Offload配置

    <Windows Azure Platform 系列文章目录> 之前有个客户提出了一个需求,他们的互联网访问的架构分为两种: 1.第一层是使用Azure Application Gatew ...

  10. sqlserver触发器执行顺序【未经验证】

    exec sp_settriggerorder @triggername = 'tr_customer_1', @order = 'first', @stmttype = 'insert',@name ...