QuerySet对象与查询优化
一、QuerySet对象
Django的ORM中存在查询集的概念。
查询集,也称查询结果集,即QuerySet,表示从数据库中获取的对象集合。
当调用如下过滤器方法时,Django会返回查询集(与列表类似,但不是简单的列表):
查询集有诸多特性,我们来一一了解它们
1、可切片
可以使用Python 的切片语法来限制查询集记录的数目,它等同于SQL 的LIMIT 和OFFSET 子句 。
不支持负的索引(例如Book.objects.all()[-1])。
*强调:不能把QuerySet单纯地当成python中的列表,它们还是有区别的。*
2、可迭代
3、惰性查询
查询集 是惰性执行的 —— 创建查询集不会带来任何数据库的访问。你可以将过滤器保持一整天,直到查询集 需要求值时,Django 才会真正运行这个查询。
一般来说,只有在“请求”查询集 的结果时才会到数据库中去获取它们。当你确实需要结果时,查询集 通过访问数据库来求值
4、缓存机制
每个查询集都包含一个缓存来最小化对数据库的访问。理解它是如何工作的将让你编写最高效的代码。
在一个新创建的查询集中,缓存为空。
当我们首次对查询集进行求值时–同时发生数据库查询 ,Django 将查询的结果保存到查询集的缓存中并返回明确请求的结果。接下来对该查询集 的求值将重用缓存的结果。
请牢记这个缓存行为,因为对查询集使用不当的话,它会坑你的。
例如,下面的两条语句查出的都是所有的书籍,但是每条都创建了新的查询集,然后各自对各自的查询集求值,这存在两大问题
• 1、相同的数据库查询将执行两次,显然倍增了你的数据库负载。
• 2、还有可能两个结果列表并不包含相同的数据库记录,因为在两次请求期间有可能有Article被添加进来或删除掉。
为了避免上述问题,只需保存查询集并重新使用它,如下
5、何时查询集不会被缓存?
1、只有在对查询集求值后才会缓存
如下操作都算是在对查询集求值,它们会使得全部的查询集被求值并填充到缓存中:
2、单纯的打印结果集不算是对查询集求值,所以不会被缓存,每次打印都会引发新的数据库查询
3、使用切片或索引来限制查询集也不算是对查询集求值,所以也不会被缓存
所以,我们可以先对查询集求值,缓存好数据之后再进行上述2和3的操作
6、exists()与iterator()方法
简单的使用if语句进行判断也会完全执行整个queryset并且把数据放入cache,如下
若仅仅只需要判断是否存在数据,那么再把所有数据集合都查询回来缓存将会极大地降低效率,此时我们可以使用exists(),只拿回来一条来判断是否存在即可,需要拿所有,当然也不会缓存
当queryset非常巨大时,cache会成为问题。
处理成千上万的记录时,将它们一次装入内存是很浪费的。更糟糕的是,巨大的queryset可能会锁住系统 进程,让你的程序濒临崩溃。要避免在遍历数据的同时产生queryset cache,可以使用iterator()方法 来获取数据,iterator并不会产生缓存,处理完数据后就丢弃了,要想重新获取数据得重新拿到iterator(),如下所示。
注意:使用iterator()方法来防止生成cache,意味着遍历同一个queryset时会重复执行查询。所以使用iterator()的时候要当心,确保你的代码在操作一个大的queryset时没有重复执行查询。
*总结:*
queryset的cache是用于减少程序对数据库的查询,在通常的使用下会保证只有在需要的时候才会查询数据库。 使用exists()和iterator()方法可以优化程序对内存的使用。不过,由于它们并不会生成queryset cache,可能 会造成额外的数据库查询。
二、跨表查询优化
select_related()
(1)简单使用
对于一对一字段(OneToOneField)和外键字段(ForeignKey),可以使用select_related 来对QuerySet进行优化,select_related底层就是链表操作
简单说,在对QuerySet使用select_related()函数后,Django会获取相应外键对应的对象,从而在之后需要的时候不必再查询数据库了,例如
但需要注意的是:select_related()括号内只能放外键Foreignkey字段
因为一对多、一对一关系均使用ForeignKey,而多对多则不是,所以select_related不支持多对多关系,若想优化多对多的查询请看下一小节 (2)多外键查询
如果一个模型中存在多个ForeignKey字段
(2)深层查询
对于跨越了n张表的深层查询, 依然需要查询多次,例如下述代码依然需要重复查询两次
这是因为第一次查询没有query到userInfo表,所以,修改如下:
(3)总结
l select_related主要针一对一和多对一关系进行优化。
l select_related使用SQL的JOIN语句进行优化,通过减少SQL查询的次数来进行优化、提高性能。
l 可以通过可变长参数指定需要select_related的字段名。也可以通过使用双下划线“__”连接字段名来实现指定的递归查询。
l 没有指定的字段不会缓存,没有指定的深度不会缓存,如果要访问的话Django会再次进行SQL查询。
l 也可以通过depth参数指定递归的深度,Django会自动缓存指定深度内所有的字段。如果要访问指定深度外的字段,Django会再次进行SQL查询。
l 也接受无参数的调用,Django会尽可能深的递归查询所有的字段。但注意有Django递归的限制和性能的浪费。
l Django >= 1.7,链式调用的select_related相当于使用可变长参数。Django < 1.7,链式调用会导致前边的select_related失效,只保留最后一个。
prefetch_related()
对于多对多字段(ManyToManyField)和一对多字段,可以使用prefetch_related()来进行优化,prefetch_related()的底层就是子查询,在使用时select_related与prefetch_related是没有差别的,但是底层是有差别的
针对一对多字段
针对多对多字段