Django之QuerySet对象与查询优化-Toy模板网

这篇具有很好参考价值的文章主要介绍了Django之QuerySet对象与查询优化。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

一、QuerySet对象

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

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

当调用如下过滤器方法时，Django会返回查询集（与列表类似，但不是简单的列表）：

all()：返回所有数据。

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

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

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

1、可切片

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

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）总结

1、select_related主要针一对一和多对一关系进行优化。

2、select_related使用SQL的JOIN语句进行优化，通过减少SQL查询的次数来进行优化、提高性能。

3、可以通过可变长参数指定需要select_related的字段名。也可以通过使用双下划线“__”连接字段名来实现指定的递归查询。

4、没有指定的字段不会缓存，没有指定的深度不会缓存，如果要访问的话Django会再次进行SQL查询。

5、也可以通过depth参数指定递归的深度，Django会自动缓存指定深度内所有的字段。如果要访问指定深度外的字段，Django会再次进行SQL查询。

6、也接受无参数的调用，Django会尽可能深的递归查询所有的字段。但注意有Django递归的限制和性能的浪费。

7、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)

针对多对多字段

books = Book.objects.prefetch_related('authors')  # 底层就是inner join
for book in books:
    for author in book.authors.all():
        print(book.name,author.name)

注意

链表与子查询的效率不一定谁高谁低
链表有可能遇到很多张表，连在一起，会在耗费很多时间在链表上
而子查询，每次都一张表，分多步运行，不需要链表，但步骤多了，有可能影响效率

通常情况下:
数据量少的话，建议用select_related
数据量比较多，建议用prefetch_related

三、only与defer

1、only

下例中，因为res是.all()得到的结果集合，所以obj.任意书籍对象自己的属性，均不再走数据库

res = Book.objects.all()

for obj in res: 
	print(obj.name)   # 不走数据库查询
	print(obj.price)  # 不走数据库查询

因为上面是.all()所以拿到的结果集必然数据量大，如果我们只想要书的名字，可以使用.only()

res = Book.objects.only('name')

for obj in res:
   print(obj.name)  # .name不走数据库 .其他字段会重新走数据库查询

2、defer

defer与only刚好相反，除了defer指定的属性外，其他都不需要查数据库

res = Book.objects.defer('name')  
for obj in res:
    print(obj.price)  # 除了.name之外，点出的属性都不需要走数据库

    # print(res)  # 打印res，会触发多条sql的执行来拿到所有的结果集，因为访问了除了name之外的属性

四、整体插入

创建对象时，尽可能使用bulk_create()来减少SQL查询的数量。例如：

Entry.objects.bulk_create([
    Entry(headline="Python 3.0 Released"),
    Entry(headline="Python 3.1 Planned")
])

...更优于：

Entry.objects.create(headline="Python 3.0 Released")
Entry.objects.create(headline="Python 3.1 Planned")

注意该方法有很多注意事项，所以确保它适用于你的情况。

这也可以用在ManyToManyFields中，所以：

my_band.members.add(me, my_friend)

...更优于：

my_band.members.add(me)
my_band.members.add(my_friend)

...其中Bands和Artists具有多对多关联。文章来源地址https://www.toymoban.com/news/detail-519198.html

到了这里，关于Django之QuerySet对象与查询优化的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！

Django之QuerySet对象与查询优化