QuerySet
1、惰性查询
2、缓存机制
3、可迭代
4、可切片
-------------------------------------------------------
在一个新创建的查询集中，缓存为空。首次对查询集进行求值 —— 同时发生数据库查询 ——Django
将保存查询的结果到查询集的缓存中并返回明确请求的结果（例如，如果正在迭代查询集，则返回下一个结果）。
接下来对该查询集 的求值将重用缓存的结果。 注意,当迭代完以后，第二次查询，仍会操作数据库
何时查询集不会被缓存?
1、重复获取查询集对象中一个特定的索引将每次都查询数据库
2、已经对全部查询集求过值，则将检查缓存
3、一些其它例子，它们会使得全部的查询集被求值并填充到缓存中
queryset = Entry.objects.all()
[entry for entry in queryset] # Queries the database
print queryset[5] # Uses cache
print queryset[5] # Uses cache
4、简单地打印查询集不会填充缓存。
exists()与iterator()方法
exists: 只是简单判断queryset集是否有数据,但并不需要这些数据,用exists
iterator:当数据量非常庞大时,一次性装入内存是非常糟糕的,
iterator()可以一次只从数据库获取少量数据，这样可以节省内存, 迭代器协议
注意：虽然iterator可以防止生成cache,但意味着遍历同一个queryset时会重复执行查询所以使 #用iterator()
的时候要当心，确保你的代码在操作一个大的queryset时没有重复执行查询。
中介模型
就是多对多模型的第三张表,有时我们不仅需要有两个foreign key,还要有一些其他的信息,因此我们需要添加一些其他的字段。
那么此时我们就不能用add,set,create这些方法来给第三张表添加数据
此时那么我们就需要用
m1=Book2auth(person=paul, group=beatles,date_joined=date(1960, 8, 1))
m1.save()
m2 = Book2auth.objects.create(person=paul, group=beatles,date_joined=date(1960, 8, 1))这两种方法来添加了
select_related与prefetch_related与defer与only
与性能有关
models.User.objects.all().only('id','name','age') # 只取
models.User.objects.all().defer('id','name','age') # 排除
only,defer 查出来的也是queryset类型，包含一个个obj
查出来的是queryset类型，其中包含一个个对象，但当获取obj以外的字段外，会另外发起一次数据库查询
select_related用于一对一和外键查询是对QuerySet进行了优化,会沿着外键关系查询对象的数据,但会生成一个复杂的查询并引起性能的损耗,但以后在使用外键关系时不需要数据库查询（join连表操作）
- 多外键查询
article=models.Article.objects.select_related("category").get(nid=1)
print(article.articledetail) 两次查询article=models.Article.objects.select_related("category","articledetail").
get(nid=1)
print(article.articledetail)
查询一次 - 深层查询
article=models.Article.objects.select_related("blog").get(nid=1)
print(article.blog.user.username) 依然要查询两次因为第一次没有查询到userinfo表 article=models.Article.objects.select_related("blog__user").get(nid=1)
print(article.blog.user.username)
一次select_related主要针一对一和多对一关系进行优化。
select_related使用SQL的JOIN语句进行优化，通过减少SQL查询的次数来进行优化、提高性能。
可以通过可变长参数指定需要select_related的字段名。也可以通过使用双下划线“__”连接字段名来实现指定的递归查询。
没有指定的字段不会缓存，没有指定的深度不会缓存，如果要访问的话Django会再次进行SQL查询。
也可以通过depth参数指定递归的深度，Django会自动缓存指定深度内所有的字段。如果要访问指定深度外的字段，Django会再次进行SQL查询。
也接受无参数的调用，Django会尽可能深的递归查询所有的字段。但注意有Django递归的限制和性能的浪费。
Django >= 1.7，链式调用的select_related相当于使用可变长参数。Django < 1.7，链式调用会导致前边的select_related失效，只保留最后一个。总结
prefetch_related() 子查询
对于多对多字段（ManyToManyField）和一对多字段，可以使用prefetch_related()来进行优化。
prefetch_related()和select_related()的设计目的很相似，都是为了减少SQL查询的数量，但是实现的方式不一样。后者是通过JOIN语句，在SQL查询内解决问题。但是对于多对多关系，使用SQL语句解决就显得有些不太明智，因为JOIN得到的表将会很长，会导致SQL语句运行时间的增加和内存占用的增加。若有n个对象，每个对象的多对多字段对应Mi条，就会生成Σ(n)Mi 行的结果表。
prefetch_related()的解决方法是，分别查询每个表，然后用Python处理他们之间的关系。
多次单表操作，先查询想要的数据，然后构造条件，如：id=[,,]，再次查询其他表根据id做条件
# 查询所有文章关联的所有标签
article_obj=models.Article.objects.all()
for i in article_obj:
print(i.tags.all()) #4篇文章: hits database 5
改为prefetch_related：
# 查询所有文章关联的所有标签
article_obj=models.Article.objects.prefetch_related("tags").all()
for i in article_obj:
print(i.tags.all()) #4篇文章: hits database 2
extra
models.Book.objects.extra(
select={"standard_time": "strftime('%%Y-%%m--%%d',create_time)'"},
# 可以再select语句中添加其他字段信息 select *** from *** as B
select_params=(),
where=['nid in (1,3) OR title like "%s"', 'nid>2'], # 各个条件之间为且的关系
params=["py", ], # 与where对应
tables=None,
order_by=["-nid", ],
)
raw
name_map = {'first': 'first_name', 'last': 'last_name', 'bd': 'birth_date', 'pk': 'id'}
# 如果SQL是其他表时，必须将名字设置为当前UserInfo对象的主键列名
models.Book.objects.raw("select id as nid from asd_userinfo",params=[],translations=name_map) # 对应关系
- 原生SQL from django.db import connection, connections
cursor = connection.cursor() # cursor = connections['default'].cursor()
cursor.execute("""SELECT * from auth_user where id = %s""", [1])
row = cursor.fetchone() # fetchall()/fetchmany(..)
PS: 选择数据库
queryset = models.Course.objects.using('default').all() # setting DATABASES 是一个字典，里面默认只有default一个数据库。
日期截断
在获取日期对象时截取年月
data_format（obj,"%Y-%m"） # 针对mysql
strftime("%%Y-%%m",obj) # 针对sqlite