索引是啥:加快检索速度的数据结构

索引的优点和缺点

索引的优点:

1.建立索引后,数据库检索数据速度直线上升(使用正确的话),数据量越大越明显

2.分组和排序的时候,可以利用索引加快速度

3.通过建立唯一索引可以确保数据唯一,不需要加其他限制条件(既建立了索引又保证了唯一性)

4.连表查询时，基于主外键字段上建立索引，可以带来十分明显的性能提升。

缺点:

1.建立索引会生成本地磁盘文件，需要额外的空间存储索引数据，磁盘占用率会变高。

2.写入数据时，需要额外维护索引结构，增、删、改数据时，都需要额外操作索引。

3.写入数据时维护索引需要额外的时间开销，执行写SQL时效率会降低，性能会下降。

各种索引的优劣

主键索引

首先过长的字段不应该作为主键索引,且主键索引字段应该唯一

所以我们一般用自增ID作为主键索引,能满足这两种需求

但是我们为啥不用UUID作为主键索引呢?这也满足我们的要求啊

因为InnoDB储存引擎在储存索引的时候,使用的是B+树作为数据结构而B+树是基于二分功能的也就是它的节点是有序的 (详情可以看下这篇博客B+树) 但UUID是随机的也就是说我们在建立索引的时候要进行随机插入而随机插入可能会打乱B+树的现有的形状而主键索引的叶节点里面包含所有数据一移动节点会移动数据这样进行数据迁移的代价极大

但使用自增ID就不会有这个问题，所有新插入的数据都会放到最后。

所以主键又加了一个要求有序

联合索引

联合索引可以实现索引覆盖减少二级索引的回表操作从而提高检索速度或者在分组及排序的时候加快速度

但是举个例子我们对 a b c字段建立联合索引

那么有三条语句

SELECT * FROM table WHERE a = 1 and b = 1 and c = 1;

SELECT * FROM table WHERE a = 1 and c = 1;

SELECT * FROM table WHERE b = 1 and c = 1;

只有第三条语句不能使用联合索引

因为查询条件的最左边的条件要和索引的最左边匹配也就是说这里的查询条件的第一个条件一定要是a 才能使用联合索引

且联合索引当遇到范围查询 (>、<) 就会停止匹配比如
select * from t_user  where age > 20 and reward = 100000;
age可以利用到联合索引而reward不行

前缀索引

前缀索引就是利用这个字段的前几个字符创建索引相较于普通的索引可以节省储存空间当数据数量高到一定程度时节省的储存空间将十分可观

但是它的索引节点中，未存储一个字段的完整值，所以MySQL也无法通过前缀索引来完成ORDER BY、GROUP BY等分组排序工作，同时也无法完成覆盖扫描等操作。

全文索引

InnoDB在MySQL 5.6及以后的版本引入的全文索引

全文索引是将存储在数据库中的大段文本中的任意内容信息查找出来的技术

假如说我们百度搜索 MYSQL很酷然后看搜索结果标红的部分就是和关键词对应的地方

我们的全文索引也就是这样的效果把要搜索的字段断成几个词根然后再全文里面检索

有没有感觉和模糊匹配的作用差不多(好像是个大模糊匹配)模糊匹配虽然能够实现效果，但随着表越来越大，数据越来越多时，其性能会出现明显下降，而全文索引的推出则能够完美解决该问题，可以利用全文索引代替like%语法实现模糊查询，它的性能会比like%快上N倍。

全文索引的缺陷:

①由于全文索引是基于分词实现的，所以对一个字段建立全文索引后，MySQL会对该字段做分词处理，这些分词结果也会被存储在全文索引中，因此全文索引的文件会额外的大！

②由于全文索引对每个字段值都会做分词，因此当修改字段值后，分词是需要时间的，所以修改字段数据后不会立马自动更新全文索引，此时需要咱们写存储过程，并调用它手动更新全文索引中的数据。

③除开上述两点外，全文索引最大的硬伤在于对中文支持不够友好，类似于英文可以直接通过符号、空格来分词，但中文呢？一个词语来形容就是博大精深，无法精准的对一段文字做分词，因此全文索引在检索中文时，存在些许精准度问题。

唯一索引

唯一索引可以保证数据唯一性当它搜索的时候只会返回一条数据不会往下查看,而普通索引会向下查看知道不满足条件,所以检索速度会快一些(实际上快不了多少因为读取行为一次读一个数据页到内存中而内存中的查询操作很快详情可见-普通索引VS唯一索引)

插入的时候呢

当当前数据页已经被加载到内存中时

唯一索引:先找到插入位置看看冲不冲突不冲突再插入

普通索引: 直接插

差了个cpu操作也大差不差

但是如果当前数据

就不行了就是唯一索引是用不了change buffer的所以每次插入操作都要进行一次I/O操作而我们知道I/O操作贼**费劲

哈希索引

(我是没见过但是了解总比不了解强对吧)

哈希索引，也就是数据结构为Hash类型的索引，不过估计大家接触的比较少，毕竟创建索引时都默认用的B+树结构。但要比起查询速度，哈希索引绝对是MySQL中当之无愧的魁首！因为采用哈希结构的索引，会以哈希表的形式存储索引字段值，当基于该字段查询数据时，只需要经过一次哈希计算就可获取到数据。

但哈希结构的致命问题在于无序，也就是无法基于哈希索引的字段做排序、分组等工作。

因此如果你确定一个表中，不会做排序这类的工作，那可以适当选用哈希结构作为索引的数据结构，它会给你带来意想不到的性能收益

索引失效

就是建立好的索引没用上直接全表扫描了

左或者左右模糊匹配

索引 B+ 树是按照「索引值」有序排列存储的，只能根据前缀进行比较。那左模糊匹配和左右模糊匹配都是前缀未知的

使用函数

假如说我们对value列建立了索引然后查询的时候用了 WHERE LENGTH(name)=6 这时候就不会使用索引原因很简单我们是对value建立了索引又不是对函数建立了索引

不过呢现在MYSQL还真只是函数索引了我们如果建立 LENGTH(name)索引的话那再查询的时候就可以走索引了呗

使用表达式

这里失效的理由和使用函数的失效是一样的例如 WHERE id + 1 = 10

但是呢如果用 WHERE id = 10 - 1 就可以因为MYSQL懒的判断所以我们自己改一改还是可以用的

隐式类型转换

比如我们刚开始定义了value VARCHAR(20) 但是在查询的时候忘记写单引号了

比如 WHERE value = 60 MYSQL就会认为你查的是int类型的然后就索引失效了

而反过来定义value INT 查询的时候加了单引号 value = '60' 就不会索引失效

为啥呢,因为:MySQL 在遇到字符串和数字比较的时候，会自动把字符串转为数字，然后再进行比较。而这个转换行为会调用函数

也就是第一种方式就等效于

where CAST(value AS signed int) = 60;

也就是发生了使用函数造成的索引失效

而第二种方式

where value  = CAST(60 AS signed int);

这次我们的被判断字段没使用函数

联合索引非最左匹配

在上面联合查询的部分介绍了

使用了OR

如果在 OR 前的条件列是索引列，而在 OR 后的条件列不是索引列，那么索引会失效。

不同字段值对比

如果我们用 WHERE name = 'zhangsan' 不会索引失效但是

如果用 WHERE name_student = name_teacher 就会失效不能用两个字段(参数)进行比较(即使建立了 name)

反向范围操作导致索引失效

一般来说，如果SQL属于正向范围查询，例如>、<、between、like、in...等操作时，索引是可以正常生效的，但如果SQL执行的是反向范围操作，例如NOT IN、NOT LIKE、IS NOT NULL、!=、<>...等操作时，就会出现问题，

不过IS NULL虽然是正向查询但是也会索引失效 IS NOT NULL也会失效

MYSQL优化器造成的索引失效

有时候二级索引的大量I/O操作(回表造成的) 还不如直接全表查询来的快 MYSQL就会自动执行成本更低的操作

例如:SELECT * FROM table WHERE a>1000000 and b <500000;

这个数据有很多行(按几万行估计) 我们的流程为

(在联合索引遇到> <的时候会停止也就是a使用索引 b不使用)

判断a是否符合要求然后拿着a的id 回表操作拿到b的数据判断

而不用索引呢
顺序遍历每一条数据由于每次加载一个数据页进来比每条进行回表减少了很多I/O操作成本大量减少了

一些索引优化行为

索引覆盖

当要查询的数据全包含在联合索引时就会直接在索引中取值而避免多次回表操作

例如 SELECT name,age FROM table WHERE.....如果name和age包含在联合索引中就不会按照正常的二级索引逻辑(找到对应主键再用主键找到整条记录的数据)

索引下推

也就是将Server层筛选数据的工作，下推到引擎层处理

例如:

SELECT * FROM table where a > 500 and b = 20;

这条SQL会部分使用索引只适用a的索引

如果没有索引下推那么它的执行过程为首先找到a>500的所有条目然后回表扫描判断b是否等于20 然后把符合的结果返回给用户

有了索引下推就是找到a>500的条目同时在联合索引中判断是否符合b=20 不符合的直接筛掉

然后直接去回表拿数据就减少了几次回表操作

MRR(Multi-Range Read)机制

Multi-Range Read简称为MRR机制，这也是和索引下推一同在MySQL5.6版本中引入的性能优化措施，那什么叫做MRR优化呢？

一般来说，在实际业务中我们应当尽量通过索引覆盖的特性，减少回表操作以降低IO次数，但在很多时候往往又不得不做回表才能查询到数据，但回表显然会导致产生大量磁盘IO，同时更严重的一点是：还会产生大量的离散IO，下面举个例子来理解。

SELECT * FROM `zz_student_score` WHERE `score` BETWEEN 0 AND 59;

上述这条SQL所做的工作很简单，就是在学生成绩表中查询所有成绩未及格的学生信息，假设成绩字段上存在一个普通索引，那思考一下，这条SQL的执行流程是什么样的呢？

①先在成绩字段的索引上找到0分的节点，然后拿着ID去回表得到成绩零分的学生信息。
②再次回到成绩索引，继续找到所有1分的节点，继续回表得到1分的学生信息。
③再次回到成绩索引，继续找到所有2分的节点......
④周而复始，不断重复这个过程，直到将0~59分的所有学生信息全部拿到为止。

那此时假设此时成绩0~5分的表数据，位于磁盘空间的page_01页上，而成绩为5~10分的数据，位于磁盘空间的page_02页上，成绩为10~15分的数据，又位于磁盘空间的page_01页上。此时回表查询时就会导致在page_01、page_02两页空间上来回切换，但0~5、10~15分的数据完全可以合并，然后读一次page_01就可以了，既能减少IO次数，同时还避免了离散IO。

而MRR机制就主要是解决这个问题的，针对于辅助索引的回表查询，减少离散IO，并且将随机IO转换为顺序IO，从而提高查询效率。

MRR机制中，对于辅助索引中查询出的ID，会将其放到缓冲区的read_rnd_buffer中，然后等全部的索引检索工作完成后，或者缓冲区中的数据达到read_rnd_buffer_size大小时，此时MySQL会对缓冲区中的数据排序，从而得到一个有序的ID集合：rest_sort，最终再根据顺序IO去聚簇/主键索引中回表查询数据。