第十节:QuerySet对象与查询优化

QuerySet对象与查询优化

一、QuerySet对象

Django的ORM中存在查询集的概念。

查询集,也称查询结果集,即QuerySet,表示从数据库中获取的对象集合。

当调用如下过滤器方法时,Django会返回查询集(与列表类似,但不是简单的列表):

all():返回所有数据。

filter():返回满足条件的数据。

exclude():返回满足条件之外的数据。

order_by():对结果进行排序。

查询集有诸多特性,我们来一一了解它们

1、可切片

可以使用Python 的切片语法来限制查询集记录的数目,它等同于SQL 的LIMITOFFSET 子句 。

res = Book.objects.all()[:5]  # limit 5
print(res)  # <QuerySet [<Book: book1>, ..., <Book: book5>]>

res = Book.objects.all()[5:7]   # LIMIT 2 OFFSET 5,偏移5所以从6开始,到7结束即limit 2
print(res)  # <QuerySet [<Book: book6>, <Book: book7>]>

不支持负的索引(例如Book.objects.all()[-1])。

*强调:不能把QuerySet单纯地当成python中的列表,它们还是有区别的。*

2、可迭代

books = Book.objects.all()
for book in books:
    print(book.name)

3、惰性查询

查询集 是惰性执行的 —— 创建查询集不会带来任何数据库的访问。你可以将过滤器保持一整天,直到查询集 需要求值时,Django 才会真正运行这个查询。

query_res = Book.objects.all()  # 不会查询数据库,终端也并无sql日志打印

print(query_res)  # 此时才会查询数据库,在开启sql日志功能后,可以在终端看到执行的原生sql

for book in query_res:
    print(book.name)  # 此时会再次查询数据库

一般来说,只有在“请求”查询集 的结果时才会到数据库中去获取它们。当你确实需要结果时,查询集 通过访问数据库来求值

4、缓存机制

每个查询集都包含一个缓存来最小化对数据库的访问。理解它是如何工作的将让你编写最高效的代码。

在一个新创建的查询集中,缓存为空。

当我们首次对查询集进行求值时–同时发生数据库查询 ,Django 将查询的结果保存到查询集的缓存中并返回明确请求的结果。接下来对该查询集 的求值将重用缓存的结果。

请牢记这个缓存行为,因为对查询集使用不当的话,它会坑你的。

例如,下面的两条语句查出的都是所有的书籍,但是每条都创建了新的查询集,然后各自对各自的查询集求值,这存在两大问题

• 1、相同的数据库查询将执行两次,显然倍增了你的数据库负载。

• 2、还有可能两个结果列表并不包含相同的数据库记录,因为在两次请求期间有可能有Article被添加进来或删除掉。

print([book.name for book in Book.objects.all()])
print([book.price for book in Book.objects.all()])

为了避免上述问题,只需保存查询集并重新使用它,如下

# 1、先保存结果集
query_res = Book.objects.all()  

# 2、然后再对结果集进行求值
print([book.name for book in query_res])  # 首次对查询集求值,会查询数据库并缓存
print([book.price for book in query_res]) # 命中缓存,无需查询数据库

5、何时查询集不会被缓存?

1、只有在对查询集求值后才会缓存

如下操作都算是在对查询集求值,它们会使得全部的查询集被求值并填充到缓存中:

[book for book in query_res]
bool(query_res)
any_obj in query_res
list(query_res)

for obj in query_res:
    print('哪怕只遍历一次,也算是对查询集求值了,会缓存Book.objects.all()的所有结果')
    break

2、单纯的打印结果集不算是对查询集求值,所以不会被缓存,每次打印都会引发新的数据库查询

query_res = Book.objects.all()
print(query_res)  # 查询数据库
print(query_res)  # 查询数据库

3、使用切片或索引来限制查询集也不算是对查询集求值,所以也不会被缓存

query_res = Book.objects.all()
print(query_res[5])  # 查询数据库
print(query_res[3:5])  # 查询数据库

所以,我们可以先对查询集求值,缓存好数据之后再进行上述2和3的操作

query_res = Book.objects.all()

123 in query_res  # 对查询集求值,会查询数据库并缓存

print(query_res)  # 命中缓存
print(query_res[5])  # 命中缓存
print(query_res[3:5])  # 命中缓存

6、exists()与iterator()方法

简单的使用if语句进行判断也会完全执行整个queryset并且把数据放入cache,如下

query_res = Book.objects.all()
if query_res:  # 查询数据库并缓存
    print('ok')

print(query_res)  # 命中缓存

若仅仅只需要判断是否存在数据,那么再把所有数据集合都查询回来缓存将会极大地降低效率,此时我们可以使用exists(),只拿回来一条来判断是否存在即可,需要拿所有,当然也不会缓存

query_res = Book.objects.all()
if query_res.exists():  # 查询数据库,但不缓存
    # SELECT (1) AS `a` FROM `app01_book`  LIMIT 1
    print('ok')

print(query_res)  # 无法命中任何缓存,需要再次查询数据库

当queryset非常巨大时,cache会成为问题。

处理成千上万的记录时,将它们一次装入内存是很浪费的。更糟糕的是,巨大的queryset可能会锁住系统 进程,让你的程序濒临崩溃。要避免在遍历数据的同时产生queryset cache,可以使用iterator()方法 来获取数据,iterator并不会产生缓存,处理完数据后就丢弃了,要想重新获取数据得重新拿到iterator(),如下所示。

books = Book.objects.all().iterator()
# iterator()可以一次只从数据库获取少量数据,这样可以节省内存

for obj in books:
    print(obj.name)

#强调:再次遍历没有打印,因为迭代器已经在上一次遍历(next)到最后一次了,没得遍历了
for obj in books:
    print(obj.name)

注意:使用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会获取相应外键对应的对象,从而在之后需要的时候不必再查询数据库了,例如

res = Book.objects.all()
for obj in res:
    print(obj.publish.name)  # 每次执行该行代码都会触发新的sql执行,效率极低
"""
底层会先去book表里查出所有的书籍id
然后每次for循环都会拿着一个书籍的id去publish表里查到对应出版社的名字
"""    

# 优化
res = Book.objects.select_related('publish')  

for obj in res:
    print(obj.publish.name)
"""
底层会先将Book与Publish对应的两张表连接成一张大表,然后一次性将大表的所有数据一次性封装给查询出来的对象
    此时对象无论是点击book表的数据还是publish表的数据都无需再走额外的数据库查询了
"""

for obj in res:
    print(obj.publish.city)
"""
第二次for循环直接使用上述缓存即可
"""

但需要注意的是:select_related()括号内只能放外键Foreignkey字段

因为一对多、一对一关系均使用ForeignKey,而多对多则不是,所以select_related不支持多对多关系,若想优化多对多的查询请看下一小节 (2)多外键查询

如果一个模型中存在多个ForeignKey字段

res = Book.objects.select_related("publish")

此时我们查询publish相关的时候,不会重复查询,如下
for obj in res:
    print(obj.publish.name)

for obj in res:
    print(obj.publish.city)

但如果我们查询的是Book内的其他ForeignKey字段,还是会重新查询
for obj in res:
    print(obj.other_fk.attr)

# 解决方案就是
res = Book.objects.select_related("publish","other_fk")

或者使用django1.7之后支持的链式操作
res = Book.objects.select_related("publish").select_related("detail")

(2)深层查询

对于跨越了n张表的深层查询, 依然需要查询多次,例如下述代码依然需要重复查询两次

article=models.Article.objects.select_related("blog").get(nid=1)
print(article.blog.user.username)  # 需要重复两次进行查询

这是因为第一次查询没有query到userInfo表,所以,修改如下:

article=models.Article.objects.select_related("blog__user").get(nid=1)
print(article.blog.user.username)

(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是没有差别的,但是底层是有差别的

针对一对多字段

# 效果与select_related()一样
res = Book.objects.prefetch_related('publish')  

for obj in res:
    print(obj.publish.name)

for obj in res:
    print(obj.publish.city)

针对多对多字段

联系管理员微信tutu19192010,注册账号

上一篇
下一篇
Copyright © 2022 Egon的技术星球 egonlin.com 版权所有 帮助IT小伙伴学到真正的技术