文章目录
1.索引前瞻
1.1什么是索引
MySQL官方对索引的定义为:索引(Index)是帮助MySQL高效获取数据的数据结构。
数据库除了数据本身之外,数据库还维护着一个满足特定查找算法的数据结构,这些数据结构以某种方式指向数据。
索引的本质:索引是数据结构。
1.2索引的优劣
优势
- 类似大学图书馆建书目索引,提高数据检索效率,降低数据库的IO成本
- 通过索引列对数据进行排序,降低数据排序成本,降低了CPU的消耗
劣势
- 实际上索引也是一张表,该表保存了主键和索引字段,并指向实体表的记录,所以索引列也是要占用空间的。
- 虽然索引大大提高了查询速度,同时却会降低更新表的速度,如果对表INSERT,UPDATE和DELETE。因为更新表时,MySQL不仅要不存数据,还要保存一下索引文件每次更新添加了索引列的字段,都会调整因为更新所带来的键值变化后的索引信息。
- 索引只是提高效率的一个因素,如果你的MySQL有大数据量的表,就需要花时间研究建立优秀的索引,或优化查询语句
1.3索引的分类
类型 | 描述 |
---|---|
唯一索引 | 索引列的值必须唯一,但允许有空值 |
复合索引 | 即一个索引包含多个列 |
单值索引 | 即一个索引只包含单个列,一个表可以有多个单列索引 |
聚集索引 | 数据库表行中数据的物理顺序与键值的逻辑(索引)顺序相同。一个表只能有一个聚集索引 |
非聚集索引 | 非主键索引的叶子节点内容是主键的值 |
覆盖索引 | 查询列在索引中就能够取得,不必从数据表中读取,换句话说查询列要被所使用的索引覆盖。 |
1.4索引的结构(B+树)
我们平时所说的索引,如果没有特别指明,都是指B/B+树结构组织的索引。
这里说一下B+树的结构
B+树是为了磁盘或其它存储设备而设计的一种平衡多路查找树
B+树的性质
1、非叶子节点的子树指针与关键字个数相同;
2、非叶子节点的子树指针p[i],指向关键字值属于[k[i],k[i+1]]的子树.(B树是开区间,也就是说B树不允许关键字重复,B+树允许重复);
3、为所有叶子节点增加一个链指针;
4、所有关键字都在叶子节点出现(稠密索引). (且链表中的关键字恰好是有序的);
5、非叶子节点相当于是叶子节点的索引(稀疏索引),叶子节点相当于是存储(关键字)数据的数据层;
6、更适合于文件系统;
非叶子节点(比如5,28,65)只是一个key(索引),实际的数据存在叶子节点上(5,8,9)才是真正的数据或指向真实数据的指针。
重点B+树的存储过程
新建一个索引,索引上只会有一个leaf节点,取名为Node A,不断的向这个leaf节点中插入数据后,直到这个节点满,这个过程如下图(绿色表示新建/空闲状态,红色表示节点没有空余空间)
当Node A满之后,我们再向表中插入一条记录,此时索引就需要做拆分处理:会新分配两个数据块NodeB & C,如果新插入的值,大于当前最大值,则将Node A中的值全部插入Node B中,将新插入的值放到Node C中;否则按照5-5比例,将已有数据分别插入到NodeB与C中。
无论采用哪种分割方式,之前的leaf节点A,将变成一个root节点,保存两个范围条目,指向B与C,结构如下图
如果当根节点Node A也满了,则需要进一步拆分:新建Node E&F&G,将Node A中范围条目拆分到E&F两个节点中,并建立E&F到BCD节点的关联,向Node G插入索引值。此时E&F为branch节点,G为leaf节点,A为Root节点:
在整个扩张过程中,Btree自身总能保持平衡,Leaf节点的深度能一直保持一致。
1.5索引的应用场合
合适的场合 | 不合适的场合 |
---|---|
主键自动建立唯一索引 | Where条件里用不到的字段不创建索引 |
频繁作为查询的条件的字段应该创建索引 | 表记录太少 |
查询中与其他表关联的字段,外键关系建立索引 | 经常增删改的表 |
频繁更新的字段不适合创建索引 | 数据重复且分布平均的表字段 |
查询中排序的字段,排序字段若通过索引去访问将大大提高排序的速度 | |
查询中统计或者分组字段 |
2.索引优化分析
2.1 Mysql瓶颈
- CPU:CPU在饱和的时候一般发生在数据装入在内存或从磁盘上读取数据时候
- IO:磁盘I/O瓶颈发生在装入数据远大于内存容量时
- 服务器硬件的性能瓶颈:top,free,iostat和vmstat来查看系统的性能状态
2.2 Explain查看执行计划
2.2.1Explain是什么
使用EXPLAIN关键字可以模拟优化器执行SQL语句,从而知道MySQL是 如何处理你的SQL语句的。分析你的查询语句或是结构的性能瓶颈
如图!
2.2.2字段解释
id
select查询的序列号,包含一组数字,表示查询中执行select子句或操作表的顺序.
三种情况:
- id相同,执行顺序由上至下
- id不同,如果是子查询,id的序号会递增,id值越大优先级越高,越先被执行
- id相同不同,同时存在,相同的按顺序执行,不同的按优先级执行
select_type
查询的类型,主要用于区别普通查询、联合查询、子查询等的复杂查询
六种情况:
- SIMPLE : 简单的select查询,查询中不包含子查询或者UNION
- PRIMARY : 查询中若包含任何复杂的子部分,最外层查询则被标记为PRIMARY
- SUBQUERY:在SELECT或者WHERE列表中包含了子查询
- DERIVED : 在FROM列表中包含的子查询被标记为DERIVED(衍生)MySQL会递归执行这些子查询,把结果放在临时表里。
- UNION : 若第二个SELECT出现在UNION之后,则被标记为UNION。
- UNION RESULT : 从UNION表获取结果的SELECT。
table
显示这一行的数据是关于哪张表的
type
访问类型
7种情况:(由优到劣)
- system : 表只有一行记录(等于系统表),这是const类型的特例,平时不会出现,这个也可以忽略不计
- const : 表示通过索引一次就找到了,const用于比较primary key或者unique索引。因为只匹配一行数据,所以很快。如将主键至于where列表中,MySQL就能将该查询转换为一个常量
- eq_ref : 唯一性索引,对于每个索引键,表中只有一条记录与之匹配,常见于主键或唯一索引扫描
- ref : 非唯一索引扫描,返回匹配某个单独值的所有行。本质上也是一种索引访问,它返回所有匹配某个单独值的行,然而,它可能会找到多个符合条件的行,所以他应该属于查找和扫描的混合体。
- range : 只检索给定范围的行,使用一个索引来选择行。key列显示使用了哪个索引,一般就是在你的where语句中出现了between、<、>、in等范围扫描。
- index : 只遍历索引树。这通常比ALL快,因为索引文件通常比数据文件小。
- all : FullTable Scan,将遍历全表以找到匹配的行。最差的一种
一般来说,得保证查询至少达到range级别,最好达到ref
possible_keys
显示可能应用在这张表中的索引,一个或多个。
查询涉及的字段上若存在索引,则该索引将被列出,但不一定被查询实际使用
key
实际使用的索引。如果为null则没有使用索引
key_len
表示索引中使用的字节数,可通过该列计算查询中使用的索引的长度。在不损失精确性的情况下,长度越短越好。
key_len显示的值为索引最大可能长度,并非实际使用长度,即key_len是根据表定义计算而得,不是通过表内检索出的。
ref
显示索引那一列被使用了,如果可能的话,是一个常数。那些列或常量被用于查找索引列上的值
rows
根据表统计信息及索引选用情况,大致估算出找到所需的记录所需要读取的行数
Extra
包含不适合在其他列中显示但十分重要的额外信息
有8种:
- Using filesort : 说明mysql会对数据使用一个外部的索引排序,而不是按照表内的索引顺序进行读取。MySQL中无法利用索引完成排序操作成为“文件排序”.
- Using temporary : 使用了临时表保存中间结果,MySQL在对查询结果排序时使用临时表。常见于排序order by 和分组查询 group by。
- USING index : 表示相应的select操作中使用了覆盖索引(Coveing Index),避免访问了表的数据行,效率不错!如果同时出现using where,表明索引被用来执行索引键值的查找。如果没有同时出现using where,表面索引用来读取数据而非执行查找动作。
- Using where : 表面使用了where过滤
- using join buffer : 使用了连接缓存
- impossible where : where子句的值总是false,不能用来获取任何元组
- select tables optimized away : 在没有GROUPBY子句的情况下,基于索引优化MIN/MAX操作或者对于MyISAM存储引擎优化COUNT(*)操作,不必等到执行阶段再进行计算,查询执行计划生成的阶段即完成优化。
- distinct : 优化distinct,在找到第一匹配的元组后即停止找同样值的工作
2.3索引使用原则
原则 | 解释 |
---|---|
全值匹配 | 复合索引会存在某列便会匹配 |
最佳左前缀法则 | 如果索引了多例,要遵守最左前缀法则。指的是查询从索引的最左前列开始并且不跳过索引中的列。 |
不在索引上计算、函数、类型转换 | 不在索引列上做任何操作(计算、函数、(自动or手动)类型转换),会导致索引失效而转向全表扫描 |
范围条件右边条件索引失效 | 存储引擎不能使用索引中范围条件右边的列 |
范围条件右边条件索引失效 | 存储引擎不能使用索引中范围条件右边的列 |
尽量使用覆盖索引 | (只访问索引的查询(索引列和查询列一致)),减少select* |
使用( !=或者<> )索引失效 | mysql在使用不等于(!=或者<>)的时候无法使用索引会导致全表扫描 |
is null,is not null索引失效 | is null,is not null 也无法使用索引 |
like以通配符开头(’$abc…’)索引失效 | like使用通配符结尾(‘abc…$’)索引不会失效,使用覆盖索引解决失效问题,查询字段必须是建立覆盖索引字段,但是当覆盖索引指向的字段是varchar(380)及380以上的字段时,覆盖索引会失效! |
字符串不加单引号索引失效 | 属于类型的自动转换,索引失效 |
or | 少用or,用它连接时会索引失效 |
2.4 查询优化
1. 合理建立索引,满足使用原则,explain分析type达到ref以上最好
2. 小表驱动大表,如in或者exists,如下
例1:
select * from A where id in (select id from B)
执行顺序:
select id from B
select * from A where A.id = B.id
当B表的数据集小于A表时,用in优于exists
例2:
注: exists会忽略select 1 清单,返回true or false,也可以设置成select X 或者其他
select * from A where exists (select 1 from B where B.id = A.id)
执行顺序:
select * from A
select * from B where B.id = A.id
当A表的数据集小于B表时,用exists优于in
3. ORDER BY子句,尽量使用Index方式排序,避免使用FileSort方式排序。
index排序原理:
从磁盘读取查询需要的所有列,按照orderby列在buffer对它们进行排序,然后扫描排序后的列表进行输出,它的效率更快一些,避免了第二次读取数据,并且把随机IO变成顺序IO,但是它会使用更多的空间, 因为它把每一行都保存在内存中了。
优化方法:
- 尽可能在索引列上完成排序操作,遵照索引建的最佳左前缀
- 当无法使用索引列,增大sort_buffer_size参数的设置
- 当无法使用索引列,增大max_length_for_sort_data参数的设置
详情结果如下:
4. GROUP BY与order by基本类似
优化方法:
- 尽可能在索引列上完成排序操作,遵照索引建的最佳左前缀
- 当无法使用索引列,增大sort_buffer_size参数的设置
- 当无法使用索引列,增大max_length_for_sort_data参数的设置
不同点:
- groupby实质是先排序后进行分组,遵照索引建的最佳左前缀
- where高于having,能写在where限定的条件就不要去having限定了。