1.索引
为什么要有索引?
通常的应用系统,读写比例在10:1左右,并且插入操做和通常的更新操做不多出现性能问题,
在生产环境中,咱们遇到最多的,也是最容易出问题的,仍是一些复杂的查询操做,
所以对查询语句的优化显然是重中之重。提及加速查询,就不得不提到索引了。
汇集索引
叶子节点整个行中的额数据
辅助索引
叶子节点存储的是索引字段 和主键值
覆盖索引
回表
联合索引
正确使用索引
1.区分度高字段
2.索引的字段数据量应该尽量小
3.优先使用汇集索引
4.联合索引 建立时 把区分度高放左边
查询时 尽量使用最左边的索引
索引越多越好?
索引可以提高效率
同时下降了写入速度
增长额外的磁盘占用
2.元类
用于建立类的类 叫元类 默认元类都是type
主要控制类的建立__init__ 类的实例化__call__
3.单例
一个类只有一个实例
何时用,你们公用一个打印机,没有必要每一个人建立新的打印机对象 共用一个对象便可
须要排序操做的字段(order_by)
须要比较操做的字段(> < >= <=)
须要过滤操做的字段( filter exclude)python
常常更新和删除 的字段不该该被索引mysql
主键一定是索引sql
外键 默认是索引 (能够不配置)数据库
属性中定义
meta中定义django
from django.db import models from apis.models import App # Create your models here. class User(models.Model): # open_id open_id = models.CharField(max_length=64, unique=True) # 昵称 nickname = models.CharField(max_length=256, db_index=True) # 关注的城市 focus_cities = models.TextField(default='[]') # 关注的星座 focus_constellations = models.TextField(default='[]') # 关注的股票 focus_stocks = models.TextField(default='[]') # 菜单app menu = models.ManyToManyField(App) class Meta: indexes = [ # models.Index(fields=['nickname']) models.Index(fields=['open_id', 'nickname']) ] def __str__(self): return self.nickname def __repr__(self): return self.nickname
===============================索引01 为何要用索引 由于项目运行中,查询操做很是频繁,为了提升用户体验,要提升查询的速度, 如何提升就靠索引(大多数性能问题都是慢查询 提到加速查,就必须用到索引) 做用: - 约束 - 加速查找02 什么是索引 搜索引导, 因此是一种单独的,物理的 有序的 存储结构,用于加速查询 例如: 字典 书的目录 车票上的车箱号 索引的本质原理就是经过不断地缩小查询范围,来下降io次数从而提高查询性能 强调:一旦为表建立了索引,之后的查询都会先查索引,再根据索引定位的结果去找数据本质都是:经过不断地缩小想要获取数据的范围来筛选出最终想要的结果,同时把随机的事件变成顺序的事件, 也就是说,有了这种索引机制,咱们能够老是用同一种查找方式来锁定数据。03 索引的影响 1.加速查询 2.下降写入(增长 删除 修改)速度 3.会额外占用磁盘空间4.索引的分类 1.汇集索引 就是主键索引 (primary key ) - 主键索引:加速查找 + 不能为空 + 不能重复 行中的完整记录存在汇集索引的叶子节点上 2.辅助索引 (unique,index) - 普通索引:加速查找 - 惟一索引:加速查找 + 不能重复 叶子节点 存储索引字段的值 还有 主键的值 使用辅助索引时 会产生两种现象 1.回表 要查的数据就不在辅助索引中 须要到汇集索引中查找 2.覆盖索引 要查的数据就在辅助索引中 - create index 索引名称 on 表名(列名,) - drop index 索引名称 on 表名 - create unique index 索引名称 on 表名(列名) - drop unique index 索引名称 on 表名 3 联合索引(多列): - 联合主键索引 - 联合惟一索引 - 联合普通索引 为是什么使用它 下降资源的占用 , 下降增删改的时间 会比单个字段的索引快 创建联合索引时 应该把区分度高放最左边 区分度低的依次往右放 按照区分度的高低 从左往右 依次排列 查询中 应该优先使用左边的索引 使用and时 无所谓书写顺序 会自动找区分度最高的 注意联合索引在查询时 若是压根没用到最左侧索引 不能加速查询 组合索引(最左前缀匹配): - create unique index 索引名称 on 表名(列名,列名) - drop unique index 索引名称 on 表名 - create index ix_name_email on userinfo3(name,email,) - 最左前缀匹配 select * from userinfo3 where name='alex'; select * from userinfo3 where name='alex' and email='asdf'; select * from userinfo3 where email='alex@qq.com'; 组合索引效率 > 索引合并 组合索引 - (name,email,) select * from userinfo3 where name='alex' and email='asdf'; select * from userinfo3 where name='alex'; 索引合并: - name - email select * from userinfo3 where name='alex' and email='asdf'; select * from userinfo3 where name='alex'; select * from userinfo3 where email='alex'; 名词: 覆盖索引: - 在索引文件中直接获取数据 索引合并: - 把多个单列索引合并使用索引的正确使用姿式 命中索引 ,条件中有索引字段匹配上 1.不管索引如何设计 没法下降范围查询的查询速度 select count(*) from usr where id > 1; 即便命中索引也没法提升效率 2.索引不该该加在值重复度很高的字段上 应该加在重复度低的字段 3. 使用and时 当 条件中出现多个索引命中时 会自定找一个区分度最高的索引来使用 4.使用or的时候 若是两边都有索引 会使用索引,可是注意 or两边都要执行 顺序依然从左往右 只有一边有索引会不会使用索引? 不会使用 没法加速查询 5.优化查询 不只仅要加索引,sql语句也须要优化 使其能命中索引 你的条件中应该使用区别度高的索引 正常开发时 优先使用汇集索引 再次 使用联合索引 若是你的条件不包含最左侧索引 不能加速查询 这时候就应该使用单个字段索引 建立索引: create index 索引名称 on usr(索引字段);索引未命中 详见49-2并非说咱们建立了索引就必定会加快查询速度,若想利用索引达到预想的提升查询速度的效果,咱们在添加索引时,必须遵循如下问题1 范围问题,或者说条件不明确,条件中出现这些符号或关键字: >、>=、<、<=、!= 、between...and...、like、 大于号、小于号 不等于!= between ...and... like2 尽可能选择区分度高的列做为索引,区分度的公式是count(distinct col)/count(*), 表示字段不重复的比例,比例越大咱们扫描的记录数越少,惟一键的区分度是1, 而一些状态、性别字段可能在大数据面前区分度就是0,那可能有人会问, 这个比例有什么经验值吗?使用场景不一样,这个值也很难肯定, 通常须要join的字段咱们都要求是0.1以上,即平均1条扫描10条记录3 =和in能够乱序,好比a = 1 and b = 2 and c = 3 创建(a,b,c)索引能够任意顺序, mysql的查询优化器会帮你优化成索引能够识别的形式4 索引列不能参与计算,保持列“干净”,好比from_unixtime(create_time) = ’2014-05-29’就不能使用到索引, 缘由很简单,b+树中存的都是数据表中的字段值,但进行检索时,须要把全部元素都应用函数才能比较, 显然成本太大。因此语句应该写成create_time = unix_timestamp(’2014-05-29’)5 and/or6 最左前缀匹配原则(详见第八小节),很是重要的原则,对于组合索引mysql会一直 向右匹配直到遇到范围查询(>、<、between、like)就中止匹配(指的是范围大了,有索引速度也慢), 好比a = 1 and b = 2 and c > 3 and d = 4 若是创建(a,b,c,d)顺序的索引, d是用不到索引的,若是创建(a,b,d,c)的索引则均可以用到,a,b,d的顺序能够任意调整。7 其余状况总结 #1. 必定是为搜索条件的字段建立索引,好比select * from s1 where id = 333;就须要为id加上索引 #2. 在表中已经有大量数据的状况下,建索引会很慢,且占用硬盘空间,建完后查询速度加快 好比create index idx on s1(id);会扫描表中全部的数据, 而后以id为数据项,建立索引结构,存放于硬盘的表中。建完之后,再查询就会很快了。 #3. 须要注意的是:innodb表的索引会存放于s1.ibd文件中,而myisam表的索引则会有单独的索引文件table1.MYI MySAM索引文件和数据文件是分离的,索引文件仅保存数据记录的地址。 而在innodb中,表数据文件自己就是按照B+Tree(BTree即Balance True)组织的一个索引结构, 这棵树的叶节点data域保存了完整的数据记录。这个索引的key是数据表的主键,所以innodb表数据文件自己就是主索引。 由于inndob的数据文件要按照主键汇集,因此innodb要求表必需要有主键(Myisam能够没有), 若是没有显式定义,则mysql系统会自动选择一个能够惟一标识数据记录的列做为主键, 若是不存在这种列,则mysql会自动为innodb表生成一个隐含字段做为主键,这字段的长度为6个字节,类型为长整型.-----wusir2. 频繁查找的列建立索引 - 建立索引 - 命中索引 ***** - like '%xx' select * from tb1 where email like '%cn'; - 使用函数 select * from tb1 where reverse(email) = 'wupeiqi'; - or select * from tb1 where nid = 1 or name = 'seven@live.com'; 特别的:当or条件中有未创建索引的列才失效,如下会走索引 select * from tb1 where nid = 1 or name = 'seven'; select * from tb1 where nid = 1 or name = 'seven@live.com' and email = 'alex' - 类型不一致 若是列是字符串类型,传入条件是必须用引号引发来,否则... select * from tb1 where email = 999; - != select * from tb1 where email != 'alex' 特别的:若是是主键,则仍是会走索引 select * from tb1 where nid != 123 - > select * from tb1 where email > 'alex' 特别的:若是是主键或索引是整数类型,则仍是会走索引 select * from tb1 where nid > 123 select * from tb1 where num > 123 - order by select name from tb1 order by email desc; 当根据索引排序时候,选择的映射若是不是索引,则不走索引 特别的:若是对主键排序,则仍是走索引: select * from tb1 order by nid desc; - 组合索引最左前缀 若是组合索引为:(name,email) name and email -- 使用索引 name -- 使用索引 email -- 不使用索引3. 查询优化神器-explain 关于explain命令相信你们并不陌生,具体用法和字段含义能够参考官网explain-output, 这里须要强调rows是核心指标,绝大部分rows小的语句执行必定很快 (有例外,下面会讲到)。因此优化语句基本上都是在优化rows。 执行计划:让mysql预估执行操做(通常正确) all < index < range < index_merge < ref_or_null < ref < eq_ref < system/const id,email 慢: select * from userinfo3 where name='alex' explain select * from userinfo3 where name='alex' type: ALL(全表扫描) select * from userinfo3 limit 1; 快: select * from userinfo3 where email='alex' type: const(走索引)4. DBA工做 慢查询优化的基本步骤 0.先运行看看是否真的很慢,注意设置SQL_NO_CACHE 1.where条件单表查,锁定最小返回记录表。这句话的意思是把查询语句的where都应用到表中返回的记录数最小的表开始查起,单表每一个字段分别查询,看哪一个字段的区分度最高 2.explain查看执行计划,是否与1预期一致(从锁定记录较少的表开始查询) 3.order by limit 形式的sql语句让排序的表优先查 4.了解业务方使用场景 5.加索引时参照建索引的几大原则 6.观察结果,不符合预期继续从0分析 慢日志 - 执行时间 > 10 - 未命中索引 - 日志文件路径 配置: - 内存 show variables like '%query%' set global 变量名 = 值 - 配置文件 mysqld --defaults-file='E:\wupeiqi\mysql-5.7.16-winx64\mysql-5.7.16-winx64\my-default.ini' my.conf内容: slow_query_log = ON slow_query_log_file = D:/.... 注意:修改配置文件以后,须要重启服务5. ******分页******* a. select * from userinfo3 limit 20,10; b. - 不让看 - 索引表中扫: select * from userinfo3 where id in(select id from userinfo3 limit 200000,10) - 方案: 记录当前页最大或最小ID 1. 页面只有上一页,下一页 # max_id # min_id 下一页: select * from userinfo3 where id > max_id limit 10; 上一页: select * from userinfo3 where id < min_id order by id desc limit 10; 2. 上一页 192 193 [196] 197 198 199 下一页 select * from userinfo3 where id in ( select id from (select id from userinfo3 where id > max_id limit 30) as N order by N.id desc limit 10 ) c. *****闫龙*****: id不连续,因此没法直接使用id范围进行查找1. ORM框架:SQLAlchemy SQLAlchemy是Python编程语言下的一款ORM框架,该框架创建在数据库API之上,使用关系对象映射进行数据库操做, 简言之即是:将对象转换成SQL,而后使用数据API执行SQL并获取执行结果。 - 做用: 1. 提供简单的规则 2. 自动转换成SQL语句 - DB first: 手动建立数据库以及表 -> ORM框架 -> 自动生成类 - code first: 手动建立类、和数据库 -> ORM框架 -> 以及表 a. 功能 - 建立数据库表 - 链接数据库(非SQLAlchemy,pymyql,mysqldb,....) - 类转换SQL语句 - 操做数据行 增 删 改 查 - 便利的功能