Django之DB数据库优化

取所有书的书名

res = models.Book.objects.values("title") #拿到的是一个列表套字典

还要for循环再res.get("title")

res=models.Book.objects.only("title")

拿到的是Book对象列表，此Book对象只封装了书名title属性

此时你可以i.price尽管Book对象里面没有封装price，但是仍然可以查到，但是会重新去DB里面查询

only括号里面没有的字段，会重新查询

而res=models.Book.objects.all()

查到的对象，已经有了对象所有的属性，想查什么就查什么，不会再走数据库。

 

defer()

res=models.Book.objects.defer("title")

拿到的仍是数据对象，他与oble()刚好相反，defer括号内放的字段不在查询出来的对象里面

想查询title字段，必须重走数据库，而如果查询的是非括号内字段，不再走数据库，可以直接.来获得。

select_related和prefetch_related 与跨表有关

  这里从book表，跨表查看出版社名字。会导致查出来的Book对象，每个都去跨表查一次出版社名

 

res=models.Book.obejcts.select_related("publish")

print(res)

这样网络请求少了，数据IO少了，相当于进行了优化，但是表如果很大，那么拼表的耗时会很长。

select_related里面只能放外键字段。只能放一对一和一对多

不能放多对多

pretch_related

多表操作除了连表操作，还可以用子查询，一张表的查询结果，当做领一张表的查询条件，比连表查询多了一次查询

子查询虽然查询次数多，但是单表先查询可能1秒，加起来2秒，不一定就慢于连表的时间，一定要看实际情况。

使用者感觉不出来两个方法的区别，只是内部的原理不同。

 

标签：title,models,res,数据库,DB,related,查询,Book,Django
来源： https://www.cnblogs.com/gyxpy/p/14733645.html