Django-ORM缓存机制，QuerySet对象，惰性查询机制详解，以及分页查询，缓存机制的坑！！_django orm 在缓存queryset的时候会select 所有字段怎么办

ORM QuerySet对象,缓存机制,分页

1. QuerySet对象(查询集合)

QuerySet对象是Django-ORM中查询数据返回的类似列表的多数据集合

返回QuerySet的过滤器方法有

all     : 返回全部数据的QuerySet[models Objects,]
filter  : 返回满足条件的QuerySet
exclude : 返回条件之外的QuerySet
order_by: 返回经过排序后的QuerySet
1
2
3
4

1.1 QuerySet对象可再次调用过滤器(查询)

QuerySet对象可以再次调用过滤器进行查询，其实等价于SQL中将查询后的数据再次查询

# 查询书籍评论量大于等于3000的书籍，查询完成后再通过销量对书籍进行降序排列
Book.objects.filter(comment_num__gte=3000).order_by('-sale')
1
2

1.2 判断一个查询集中是否有数据

# exists() : 判断查询集是否有数据，有则返回True，反之False
# 查询书籍评论量大于等于5000000的书籍
res = Book.objects.filter(comment_num__gte=5000000)
res.exists() -> False
# 用于查询结果判断
1
2
3
4
5

1.3 查询集的切片

查询集是一种类似于list的数据类型，他同样支持索引以及切片

Tips：查询集的切片不支持 负数索引

# 查询销量大于200的书籍
res = Book.objects.filter(sale__gte=200)
res[0] # 取出第一个对象
res[0:10] # 取出0-9个对象
res[-1] # 不支持！！！
1
2
3
4
5

1.4 分页查询

在实际项目中，我们往往会遇到需要分页进行查询的情况，例如用户列表，每页展示前10条，用户翻页后查询第二页

Django为我们封装了分页查询类

Django文档:

Paginator 类¶

Tips:

1. Paginator类的页码都从1开始，而非0，返回的range对象也是1开始

from django.core.paginator import Paginator # 导入分页类
# Paginator类可以对任意有序可迭代对象进行分页,例如list,QuerySet
# 这里引用官方例子-list分页

>>> objects = ["john", "paul", "george", "ringo"]
>>> p = Paginator(objects, 2) # 每页有几个数据
>>> p.count # 获取p对象的个数
4
>>> p.num_pages # 获取p的页数
>>> p.page_range
range(1, 3) # 返回一个和page页数对应的range对象

>>> page1 = p.page(1) # 获取第一页的所有对象
>>> page1
<Page 1 of 2>
>>> page1.object_list # 获取page1对象的值
['john', 'paul']
>>> page1.has_next() # page是否还有下一页
True
>>> page2.has_previous() # page是否有前一页
False
>>> page2.has_other_pages() # 是否还有其他页
True
>>> page2.next_page_number() # 下一页的页码 (如果没有下一页,则抛出 EmptyPage 异常)
2
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

2. 惰性查询以及缓存机制

ORM中为了防止对一个数据的多次重复在SQL进行查询，而导致的性能问题，Django提供了惰性查询机制和缓存机制，使用起来非常方便

2.1 惰性查询机制：只有我们真正调用查询语句的时候才会调用SQL

# 当我们定义一个objects
obj = Book.objects.all() # 此时，仅仅是定义了obj需要返回所有的数据，但是并没有返回
# 此时，ORM并没有调用SQL语句
# 只有 for循环调用 或者其他方法进行数据渲染的时候才会真正查询
print(obj) # 此时，才是真正调用了查询语句
1
2
3
4
5

2.2 缓存机制：重复调用相同数据的时候，不进行新的SQL语句查询

2.2.1 缓存机制例子

#### 方式1
 print([e.pub_date for e in Entry.objects.all()])
 print([e.pub_date for e in Entry.objects.all()])
 print([e.pub_date for e in Entry.objects.all()])
#### 方式2
 queryset = Entry.objects.all()
 print([p.headline for p in queryset])
 print([p.headline for p in queryset])
 print([p.headline for p in queryset])
1
2
3
4
5
6
7
8
9

看起来也许没有啥区别，都是调用查询所有，但其实不然

方式1的查询，每次调用print()都会让ORM重新从数据库中执行SQL语句

  print([e.pub_date for e in Entry.objects.all()]) # 执行SQL
  print([e.pub_date for e in Entry.objects.all()]) # 执行SQL
  print([e.pub_date for e in Entry.objects.all()]) # 执行SQL
1
2
3

方式2的查询，则会将obj的结果缓存到内存，当调用obj的时候，直接查询缓存中对应的数据

 queryset = Entry.objects.all() # 获取对象(不执行SQL[惰性机制])
 print([p.headline for p in queryset]) # 查询SQL
 print([p.headline for p in queryset]) # 不查询，缓存中取值
 print([p.headline for p in queryset]) # 不查询，缓存中取值
1
2
3
4

所以，其实方式2并不会获取到实时的数据，所以对于数据更新要求高的，不适用方式2，下方例子展示了方式1/2的不同结果

>>> objs = Book.objects.all() # 获取一个objs对象

>>> Book.objects.create(
    name='66666新增数据',
    pub_time='1955-11-25',
    author='Ruan')  # 通过create新增一条数据


>>> for obj in objs:
		print(obj.name) # 执行objs的迭代
# 可以发现 "66666新增数据" 并查不到,这是因为缓存并没有更新SQL数据
>>> for obj in Book.objects.all() # 这种迭代是可以查到的
1
2
3
4
5
6
7
8
9
10
11
12

2.3 缓存机制的坑！！！！！

坑：如果截止至某次查询时，queryset仍未被完整迭代过，那么它的缓存仍是空的，你此前对此queryset的任何切片索引的返回结果都不会被缓存。

QuerySet，其中有一个缓存空间，当触发某种查询条件时，缓存空间增加SQL查询到的数据

当进行二次对数据调用的时候，不再调用SQL，直接从缓存空间取值

！！！但是这里有个关键点，是不是无论什么情况，只要使用了变量，他后面都是只查询一次，然后调用缓存空间呢？？

其实不是这样的，看下面这个例子

# 例子1
>>> queryset = Book.objects.all() # 定义对象
>>> print(queryset[5]) # 第一次查询用了SQL
>>> print(queryset[5]) # 这里发现，又去调用了SQL,没有用缓存
1
2
3
4

# 例子2
>>> queryset = Entry.objects.all() # 定义对象
>>> [entry for entry in queryset] #  查询数据库
>>> print(queryset[5]) # 不执行SQL,使用缓存
>>> print(queryset[5]) # 不执行SQL,使用缓存
1
2
3
4
5

通过上面两种例子，可以发现，只有我们通过for循环，将数据彻底迭代完，才会激活缓存机制