数据库优化查询相关

only与defer

orm内所有的语句操作都是惰性查询:只会在你真正需要数据的时候才会走数据库,如果你单单只写orm语句时不会走数据库的,这样设计的好处在于减轻数据库的压力

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

res = models.Book.objects.values(‘title‘)
print(res)
for r in res:
    print(r.title)

res = models.Book.objects.only(‘title‘)
print(res)
for r in res:
     print(r.title)  # 只走一次数据库查询
     print(r.price)  # 当你点击一个不是only括号内指定的字段的时候 不会报错 而是会频繁的走数据库查询

res1 = models.Book.objects.defer(‘title‘)  # defer与only是相反的
for r in res1:  # defer会将不是括号内的所有的字段信息 全部查询出来封装对象中
     #一旦你点击了括号内的字段  那么会频繁的走数据库查询
    print(r.price)

总结:用only它会帮你拿到括号内的字段的数据放在一个对象里面,当你拿该字段的数据时就不会再走数据库查询了,但如果你要那其它字段的数据,还是会去数据库查询,而defer与only是完全相反的,defer做的事情则是把你不是括号中字段的数据拿到,封装在对象中,如果你要拿一个不是括号内字段的数据时,它就可以直接而给,而不再去走数据库,如果括号内字段数据的话,它会帮你去数据库查询。

select_related与prefetch_related

select_related帮你直接连表操作 查询数据   括号内只能放外键字段
res = models.Book.objects.all().select_related(‘publish‘)
for r in res:
    print(r.publish.name)
res = models.Book.objects.all().select_related(‘publish__xxx__yyy__ttt‘)
print(res)
res = models.Book.objects.all()
"""
select_related:会将括号内外键字段所关联的那张表  直接全部拿过来(可以一次性拿多张表)跟当前表拼接操作
从而降低你跨表查询 数据库的压力

注意select_related括号只能放外键字段(一对一和一对多)
res = models.Book.objects.all().select_related(‘外键字段1__外键字段2__外键字段3__外键字段4‘)
"""
prefetch_related  不主动连表
res = models.Book.objects.prefetch_related(‘publish‘)
"""
不主动连表操作(但是内部给你的感觉像是连表操作了)  而是将book表中的publish全部拿出来,在取publish表中将id对应的所有的数据取出
res = models.Book.objects.prefetch_related(‘publish‘)
括号内有几个外键字段 就会走几次数据库查询操作
"""
for r in res:
    print(r.publish.name)

总结:

1、select_related是主动连表操作,它的作用其实就是把你括号内的外键所关联的表和你当前这张表拼接起来,变成一张表,相当于拿到了所有的数据,你想查谁就能查谁,如果你关联外键的那张表里也有外键,你可以在括号里写当前这张表的外键之后双下划线然后写那张表的名字(例如‘外键1__外键2__外键3__外键4‘),这样的话就是把这几张表全部拼接在了一起,这个的本质其实就是通过sql的join来优化查询,从而减少sql查询次数。

2、prefetch_related是不主动连表操作,它的本质其实是分别拿到两张表,然后通过python来处理表的关系,并将对应的数据拿出来封装到一个对象里,也可以让你用点操作拿出来,它看起来也像是连表操作。

事务

本质和mysql的事务差不多

也拥有ACID四大特性:原子性、一致性、隔离性、永久性

from django.db import transaction

with transaction.atomic():
    """数据库操作
    在该代码块中书写的操作 同属于一个事务
    """
    models.Book.objects.create()
    models.Publish.objects.create()
    # 添加书籍和出版社 就是同一个事务 要么一起成功要么一起失败
print(‘出了 代码块 事务就结束‘)

原文地址:https://www.cnblogs.com/wangnanfei/p/11557817.html

时间: 2024-07-30 14:57:12

数据库优化查询相关的相关文章

数据库优化查询的方法以及大访问量到数据库时的优化

一.数据库优化查询的方法 1.使用索引: 应尽量避免全表扫描,首先考虑在where 以及 order by  ,group  by 涉及的列上建立索引 2.优化SQL语句: 1>通过explain(查询优化神器)用来查看SQL语句的执行效果,可以帮助选择更好的索引和优化查询语句,写出更好的优化语句.通常我们可以对比较复杂的尤其是涉及到多表的SELECT语句,把关键字explain加到前面,查看执行计划,例如: explain select * from news; 2>任何地方都不要使用sel

orm常用字段和数据库优化查询

一.Django ORM 常用字段和参数 1.常用字段 models中所有的字段类型其实本质就那几种,整形varchar什么的,都没有实际的约束作用,虽然在models中没有任何限制作用,但是还是要分门别类,对于校验性组件校验非常有用就比如说邮箱类型,你在输入邮箱的时候如果不按照邮箱格式输入,瞎鸡儿输入会提示你不合法,虽然输入的是字符串,但是不是规定的邮箱字符串 AutoField() [int primary key auto_increment)] int自增列,必须填入参数 primary

MS数据库优化查询最常见的几种方法

1.没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷) 2.I/O吞吐量小,形成了瓶颈效应. 3.没有创建计算列导致查询不优化. 4.内存不足 5.网络速度慢 6.查询出的数据量过大(可以采用多次查询,其他的方法降低数据量) 7.锁或者死锁(这也是查询慢最常见的问题,是程序设计的缺陷) 8.sp_lock,sp_who,活动的用户查看,原因是读写竞争资源. 9.返回了不必要的行和列 10.查询语句不好,没有优化 可以通过如下方法来优化查询 1.把数据.日志.索引放到不同的I/O

数据库优化查询

only与defer orm内所有的语句操作都是惰性查询:只会在你真正需要数据的时候才会走数据库,如果你单单只写orm语句时不会走数据库的,这样设计的好处在于减轻数据库的压力 res = models.Book.objects.all() print(res) res = models.Book.objects.values('title') print(res) for r in res: print(r.title) res = models.Book.objects.only('title

数据库优化查询方法

1.对查询进行优化,应尽量避免全表扫描,首先应考虑在where及order by涉及的列上建立索引 2.应尽量避免在where子句中使用!=或<>操作符,否则引擎将放弃使用索引而进行全表扫描 3.任何地方都不要使用select * from t,用具体的字段列表代替“ * ”,不要返回用不到的任何字段 4.尽量避免大事务操作,提高系统并发能力 5.尽量避免向客户端返回大数据量,若数据量过大,应该考虑相应需求是否合理 原文地址:https://www.cnblogs.com/Fairy-Prin

数据库优化概览

数据库优化,一直是很让人头疼的事,尤其对于当前互联网发展到了一定的时期,数据量达到了一定的数量级,处理数据比较慢,这方面的知识就显得尤为重要了.这里就大概来说下数据库优化的相关知识. 先说下当前数据库大部分都还是以关系型数据库为主流,但是现在NoSQL也慢慢变得越来越重要了,毕竟现在是大数据时代,但是这里主要是讲关系型数据库. 数据优化是①找出系统瓶颈:②合理结构设计和参数调整,提高响应速度:③节省系统资源.其原则是①减少系统瓶颈:②减少资源占用:③增加系统反应速度.一般包括优化查询和优化数据库

转载:30多条mysql数据库优化方法,千万级数据库记录查询轻松解决

1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引. 2.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描, Sql 代码 : select id from t where num is null; 可以在 num 上设置默认值 0,确保表中 num 列没有 null 值,然后这样查询: Sql 代码 : select id from t where num=0; 3.应尽量避免在 wh

优化查询 数据库优化

数据库优化的目标无非是避免磁盘I/O瓶颈.减少CPU利用率和减少资源竞争.查询优化规则:在访问数据库表的数据(Access Data)时,要尽可能避免排序(Sort).连接(Join)和相关子查询*作.经验告诉我们,在优化查询时,必须做到: ① 尽可能少的行: ② 避免排序或为尽可能少的行排序,若要做大量数据排序,最好将相关数据放在临时表中*作:用简单的键(列)排序,如整型或短字符串排序: ③ 避免表内的相关子查询: ④ 避免在Where子句中使用复杂的表达式或非起始的子字符串.用长字符串连接:

数据库理论之视图、事务、索引、优化查询

数据库理论之视图.事务.索引.优化查询 一.视图 灵魂三问 1.什么是视图 视图就是通过查询得到一张虚拟表,然后保存下来,下次直接使用即可 2.为什么要用视图 如果要频繁的使用一张虚拟表,可以不用重复查询 3.如何使用视图 create view 视图名 as sql语句 注意:创建出来的视图只有表结构,数据来源还是原来的表 视图通常都是用于查询,所以尽量不要修改视图中的数据 思考:开发过程中应不应该使用视图? 不应该 二.触发器 命名规则及理论 在满足对某张表数据的增删改的情况下,自动触发的功