索引相关

索引

为社么要使用索引

• 避免全表扫描，快速查询数据

数据库中有什么信息可以成为索引

• 主键、唯一键及普通键等

索引的数据结构

• 生成索引，建立二叉查找树进行二分查找

• 生成索引，建立B-Tree结构进行查找

• 生成索引，按照B+-Tree结构进行查找 Mysql索引

• 生成索引，按照Hash结构进行查找

• 普通的二叉查找树会被深度限制搜索速度，深度增加1，就多进行一次IO。

  B+Tree，Hash，BitMap

  MySQL不支持BitMap，且支持InnoDB和MYISAM的

  MySQL不显式支持Hash

B-Tree

• ​ 根节点至少包含两个孩子，根节点的孩子数为m
• ​ 树中每个节点最多含有m个孩子（m大于等于2）
• ​ 除了根节点和叶子节点外，其他每个节点至少含有ceil个节点（m/2向上取整）
• ​ 所有叶子节点都位于同一层
• ​ 假设每个非终端节点中包含n个关键字信息，其中：

​ a： Ki 为关键字，关键字按升序排列，Ki<K（i-1）

​ b: 关键字个数n，：ceil<=n<=m-1

​ c: 非叶子节点的指针：p[1],p[2],….p[m],其中p[1]指向关键字小于K[1]的子树，p[m]指向关键字大于K[m-1]的子树，其他p[i],指向关键字属于（K[i-1],K[i]）的子树

B+ Tree

• 非叶子节点的子树指针与关键字个数相同
• 非叶子节点的子树指针P[i], 指向关键字值属于（K[i-1],K[i]）的子树
• 非叶子节点只用来索引，数据都保存在叶子节点中
• 所有叶子节点均有一个链指针指向下一个叶子节点（支持范围统计，一旦定位到一个叶子节点，就可以做横向的范围统计

B+ Tree 更适合用来做存储索引

• B+Tree的磁盘读写代价更低
• B+Tree的查询效率更加稳定
• B+Tree更有利于对数据库的扫描

Hash索引

缺点

• 都是根据哈希函数运算后的值，和原来的排序不一定对应

• 仅能满足 = IN，不能使用范围查询

• 无法用来被避免数据的排序操作

• 不能利用部分索引键查询

• 不能避免表扫描

• 遇到大量哈希值相等的情况，效率不一定比B+Tree高，哈希碰撞问题

  BitMap索引 位图索引 未普及

B+Tree索引和Hash索引的区别

• ​ 哈希索引适合等值查询（in，=），无法进行范围查询，因为哈希索引是键值对的数据结构，多个数据在存储关系上是完全没有任何顺序关系的，无法利用索引进行排序，而且哈希索引不支持多列联合索引的最左匹配原则，如果有大量重复键值的情况下，哈希索引的效率会很低，因为会发生哈希碰撞问题。
• ​ 而B+Tree是一种多路平衡树，（简述一下结构特性）节点是天然有序的，可以进行范围查询，不需要进行全表扫描，B+Tree的磁盘读写代价更低，B+Tree的查询效率更加稳定

B+Tree的叶子节点都存放哪些东西？

• 可能存放的整行数据，也可能是主键的值
• 两者的区别：索引B+Tree的叶子节点存储了整行数据的主键索引，也被称之为聚簇索引，而索引B+TREE的叶子节点存放的是主键的值的是非主键索引，也叫非聚簇索引

​

• 密集索引和疏松索引的区别

• 疏松索引中的每个搜索码值都对应一个索引值

• 疏松索引文件只为索引码的某些值建立索引项

• 聚簇索引更快

  ​ 原因：主键索引的叶子节点直接就是我们要查询的正航数据了。而非主键索引的节点是主键的值，查到主键的值之后，还需要再通过主键的值进行回表查询

InnoDB中的聚簇索引

• 若一个主键被定义，该主键则作为密集索引
• 若没有主键被定义，该表的第一个唯一非空索引则作为密集索引
• 若不满足以上条件，InnoDB则会生成一个隐藏主键（密集索引）
• 非主键索引存储相关键位和其对应的主键值，包含两次查找

InnoDB 的索引和数据存储在一个文件中（B+Tree）

MYISAM的索引和数据分开存储（稀疏索引）

非主键查询一定会查询多次吗

不一定，原因：

​ 覆盖索引（covering index）指一个查询语句的执行只需要从索引中就能取得，不必从数据表中读取。也可以称之为索引覆盖。

​ 当一条查询语句符合覆盖索引条件时，Mysql只需要通过索引就可以返回查询所需的数据，这样避免了查到索引后再回表操作，减少I/O提高效率，

​ 如：covering_index_sample中有一个普通索引：idx_key1_key2(key1,key2)。当我们通过SQL语句select key2 from covering_index_sample where key1=”keyset” 的时候，就可以通过覆盖索引查询，无需回表

​ 覆盖索引是select的数据列只用从索引中就能够取得，不必读取数据行，换句话说查询列要被所建的索引覆盖。索引的字段不只包含查询列，还包含查询条件、排序等。

在创建索引的时候会考虑哪些因素呢？

​ 对查询频率较高，经常作为where条件的字段设置索引

​

联合索引和多个单列索引

通俗理解：

• 利用索引中的附加列，您可以缩小搜索的范围，但使用一个具有两列的索引 不同于使用两个单独的索引。复合索引的结构与电话簿类似，人名由姓和名构成，电话簿首先按姓氏对进行排序，然后按名字对有相同姓氏的人进行排序。如果您知道姓，电话簿将非常有用；如果您知道姓和名，电话簿则更为有用，但如果您只知道名不姓，电话簿将没有用处。

• 所以说创建复合索引时，应该仔细考虑列的顺序。对索引中的所有列执行搜索或仅对前几列执行搜索时，复合索引非常有用；仅对后面的任意列执行搜索时，复合索引则没有用处。

重点：

​ 多个单列索引在多条件查询时优化器会选择最优索引策略，可能只用一个索引，也可能将多个索引全用上！ 但多个单列索引底层会建立多个B+索引树，比较占用空间，也会浪费一定搜索效率，故如果只有多条件联合查询时最好建联合索引！

最左前缀原则

1. MySQL会向右一直匹配到范围查询（>,<,like ,between）就停止匹配，比如a=3and b=4 and c>5 and d=6 如果简历以（a,b,c,d）为顺序的索引，d是用不到索引的，如果建立（a,b,d,c ）顺序的索引则都可以匹配到，a,b,d 的顺序可以任意调整
2. = 和in可以乱序比如a=1and b=2and c=3 建立（a,b,c）索引可以任意顺序，MySQL查询优化器会自动优化成索引可以识别的形式

联合索引最左匹配原则的成因

​ MySQL创建复合索引的规则是首先对符合索引的最左边的，也就是第一个索引字段上的数据进行排序，在第一个字段排序的基础上再对后面第二个索引字段进行排序，相当于实现了类似，order by 字段1，order by 字段2这样一种排序规则，所以第一个字段是绝对有序的，而第二个字段是无序的，因此直接对第二个字段进行条件判断是用不到索引的

顾名思义是最左优先，以最左边的为起点任何连续的索引都能匹配上，

注：如果第一个字段是范围查询需要单独建一个索引

注：在创建联合索引时，要根据业务需求，where子句中使用最频繁的一列放在最左边。因为Mysql索引查询会遵循最左优先原则，即最左优先，在检索数据时从联合索引的最左边开始匹配

​ （这样的话扩展性较好，比如 userid 经常需要作为查询条件，而 mobile 不常常 用，则需要把 userid 放在联合索引的第一位置，即最左边）

​

联合索引本质：

当创建(a,b,c)联合索引时，相当于创建了(a)单列索引，(a,b)联合索引以及(a,b,c)联合索引

想要索引生效的话,只能使用 a和a,b和a,b,c三种组合；当然，我们上面测试过，a,c组合也可以，但实际上只用到了a的索引，c并没有用到！

同时存在联合索引和单列索引（字段有重复的），这个时候查询mysql会怎么用索引呢？

这个涉及到mysql本身的查询优化器策略了，当一个表有多条索引可走时, Mysql 根据查询语句的成本来选择走哪条索引；

有人说where查询是按照从左到右的顺序，所以筛选力度大的条件尽量放前面。网上百度过，很多都是这种说法，但是据我研究，mysql执行优化器会对其进行优化，当不考虑索引时，where条件顺序对效率没有影响，真正有影响的是是否用到了索引！

其他知识点：

1、需要加索引的字段，要在where条件中

2、数据量少的字段不需要加索引；因为建索引有一定开销，如果数据量小则没必要建索引（速度反而慢）

3、如果where条件中是OR关系，加索引不起作用

4、联合索引比对每个列分别建索引更有优势，因为索引建立得越多就越占磁盘空间，在更新数据的时候速度会更慢。另外建立多列索引时，顺序也是需要注意的，应该将严格的索引放在前面，这样筛选的力度会更大，效率更高。

在MySQL 5.6中，对索引做了哪些优化吗？

​ Index Condition Pushdown（索引下推） MySQL 5.6引入了索引下推优化，默认开启，使用SET optimizer_switch = ‘index_condition_pushdown=off’;可以将其关闭。官方文档中给的例子和解释如下： people表中（zipcode，lastname，firstname）构成一个索引

​ SELECT * FROM people WHERE zipcode=‘95054’ AND lastname LIKE ‘%etrunia%’ AND address LIKE ‘%Main Street%’;

​ 如果没有使用索引下推技术，则MySQL会通过zipcode='95054’从存储引擎中查询对应的数据，返回到MySQL服务端，然后MySQL服务端基于lastname LIKE '%etrunia%'和address LIKE '%Main Street%'来判断数据是否符合条件。 如果使用了索引下推技术，则MYSQL首先会返回符合zipcode='95054’的索引，然后根据lastname LIKE '%etrunia%'和address LIKE '%Main Street%'来判断索引是否符合条件。如果符合条件，则根据该索引来定位对应的数据，如果不符合，则直接reject掉。 有了索引下推优化，可以在有like条件查询的情况下，减少回表次数。

sql调优：

如何定位并优化慢查询sql

​ 1.根据慢日志定位慢查询sql

​ 2.使用explain等工具分析sql

​ 3.修改sql或者让sql尽量走索引

explain关键字段

​ type：

​ index>all（都走全表扫描）

​ extra：

​ Using filesort 表示，Mysql会对结果按照外部索引次序排序，而不是从表里按照索引次序读到相关的内容，可能在内存或者磁盘上进行排序。MySQL中无法用索引完成的排序操作叫做“文件排序”

​ Using temporary ：表示MySQL在对查询结果排序时使用的时临时表。常见于排序order by和分组查询group by

创建索引却不执行的情况

​ 查询优化器：一条SQL语句的查询，可以有不同的执行方案，最终选择哪种方案，时通过查询优化器来选择的，，选择成本最低的方案，在一条语句真正的执行之前，MySQL的查询优化器会找出执行该语句所有可能使用的方案，对比之后找出成本最低的方案。这个成本最低的方案就是所谓的执行计划。

​ 优化过程如下：1.根据搜索条件，找出所有可能使用的索引2.计算全表扫描的代价3.计算使用不同索引执行查询的代价4.对比各种执行方案的代价，找出成本最低的。

​ 可以利用force index（）强制执行index

MySQL****的查询优化器的最重要的目标是尽可能的使用索引，并且使用最严格的索引，来消除尽可能多的数据行，最终目标是提交select语句来查找数据行，而不是排除数据行。

​ 优化器排除数据行的原因在于，他排除数据行的速度越快，找到与条件匹配的数据行也就越快

没选择主键索引的大致原因，应该是由于密集索引的叶子节点，把其他列的数据，也存放到了叶子节点当中

索引是建立的越多越好吗？

​ 数据量小的表不需要建立索引，创建索引会增加额外的开销

​ 数据变更需要维护索引，因此更多的索引意味着更高的维护成本

​ 更多的索引也意味着需要更多的空间