前言
正确的创建合适的索引是提升数据库查询速度的基础！
一、索引谁实现的
在整个数据库流程当中，客户端先和服务器进行连接，然后会经过整个MYSQL的应用服务层， 但是，索引的查询和使用，
并不是在MYSQL的服务层使用的，而是在MYSQL的存储层面由存储引擎去使用
二、索引的定义
索引是为了加速对表中数据行的检索而创建的一种分散存储的 数据结构。
这里记住，他是一种数据结构， 而且是一组逻辑结构。 类似于链表
为什么要用索引？
索引能极大的减少存储引擎需要扫描的数据量
索引可以把随机IO变成顺序IO
索引可以帮助我们在进行分组、排序等操作时，避免使 用临时表
三、为什么选择B+Tree
1.二叉树
MYSQL采用树形式去对于索引进行管理。 传统树结构，我们第一反应是二叉树.
但是，传统二叉树存在一个这样的弊端，如下图
当数据成有序递增时，传统二叉树结构在存储数据的时候，会形成链表形式， 那么当如果我现在要找到最后一条记录的时候
相当于是进行了一次全表扫描。 可能还不如直接全表扫描来的快。这时衍生出另外一个树结构，平衡二叉树
2.平衡二叉树
平衡二叉树的原理是保证了树与树之间子节点的高度差不超过1。
如下图所示
这时候，我们假象，如果现在我要拿关键字为10的数据，那么可能我运气比较好，第一次命中？就直接提取？
MYSQL会是这样做的吗？
NO,NO,NO，并不是。
这个时候考虑两个问题
数据量1亿？
树有多大？
OS在进行数据加载的时候，遵循的是4K的原则， 一条记录有4K吗？
所以里有两个弊端存在：
2.1.数据太深
数据处的（高）深度决定着他的IO操作次数，IO操作耗时大
看上图，七个数据，走3次？
1个亿呢？走几次？
2.2.数据太少
每一个磁盘块（节点/页）保存的数据量太小了
没有很好的利用操作磁盘IO的数据交换特性，
也没有利用好磁盘IO的预读能力（空间局部性原理），
从而带来频繁的IO操作
空间局部性原理：操作系统去硬盘中读取数据， 一次读取为1页， 操作系统认为1页数据是4K，参考SSD 4K对齐原理。
操作系统有一个预读操作，比如，我们去读取一张图片， 这个图片有2M大小。当我们去读到他的头部的4K数据之后，
他会认为我们马上回用到另外的4K或者8K,16K数据， 也就是一次交互不单单是拿4K数据，他会利用空间局部性原理去
加载更多的数据
那么也就是所，我通过一次IO读取，加载回来的数据， 其实只有一点点是我们想要的，这样也浪费了我们大量的IO性能
当树太深的时候， 我们会做很多无用的IO操作，带来了频繁的IO操作
所以从这两个角度来讲， 这个结构也不适合我们做MYSQL的一个存储结构
这个时候为了解决这两点，就想到了另外一种数据结构 多路平衡二叉树也叫B-TREE
3.多路平衡二叉树 B-TREE
那么我们来看一下B-TREE怎么保持树平衡
这个时候我们会看到，他的原则是，将中间的给顶上去。
在查询的时候， 他会给出一个中间区域 如下图，现在要找88，这个数介于77-99那么就会找到中间的这个引用节点中
如上图， 多路平衡二叉树， 其实就是所谓的23树的增强版N N+1数， 这个数从直观意义上就先解决的平衡二叉树的树太深的弊端、
平衡二叉树3层节点只能支持7个，而这个结构,只要多扩展1路就能支持30+（具体没去数，你们自己数吧），
再来看IO问题， 现在假定1个磁盘块是16K ，那么接下来我们来算一笔账
磁盘块16K：
索引类型ID 为整形， int 数据大小 4B , 就算我给他多算一点算成8B
那么是否我每一个节点，用多路的形式，我可以保存
16 *
/ 8 + 1 个？
我们现在看到的是3路，那么就是当前节点2 下属节点 2+1=3
这个时候，我们就要探寻一个问题，我们经常会听到一个概念，用来做索引的列，能精简到什么程度就精简到什么程度
原因就是
假定： 字段PHONE 是否可以定义成256个长度？可以。
但是，如果这个字段作为索引，那么现在多路二叉树能开辟的路数就变成了 16 * 1024 / 256
如果是长度为11 那么多路二叉树能开辟的路数为16 * 1024 / 11
基于这个原理， 我们一般要求是，能尽量缩减容量， 我们就缩减容量
4.增强多路平衡二叉树 B+TREE
Mysql最终采用的是左闭合B+Tree的形式，
就算MYSQL在第二层命中了当前索引，但是并不会在第二层返回，
一致找到最后一层， 所有数据全部存储在叶子节点中。
为什么选用B+Tree?
4.1、B+树是B-树的变种（PLUS版）多路绝对平衡查找树，他拥有B-树的优势B+树扫库、表能力更强
4.2、B+树的磁盘读写能力更强 B+树的排序能力更强 B+树的查询效率更加稳定
B+TREE 和 B-TREE其原理基本一致，
但是B-TREE无法保证查询的稳定性
假定数据量：1亿
第一次查询运气好：第二层找到， 耗时0.01秒
第二次查询比较背：第200层找到， 耗时0.2秒
两次同样的查询耗时完全不一致， MYSQL在进行运行判断的时候就会出现不稳定
我们一般强调的是数据的稳定性
所以采用B+TREE 每次查询到最后一个，这样更加稳定， 而并不是极致去追求速度
4.1.B+TREE 和B-Tree的区别
4.1.1、B+节点关键字搜索采用闭合区间
4.1.2、B+非叶节点不保存数据相关信息，只保存关键字和子节点的引用
4.1.3、B+关键字对应的数据保存在叶子节点中
4.1.4、B+叶子节点是顺序排列的，并且相邻节点具有顺序引用的关系
四、B+Tree在两大引擎中的体现方式
1.myisam中的存储形式
数据和索引是单独分开的。
举例：
这是看到当一个标用myisam存储引擎进行存储的时候，那么生成的物理文件有3个
FRM 表结构
MYI 表数据
MYD 表索引
在这里我们可以看到， myisam对于索引的处理是，直接将索引分开成了一个独立的数据文件进行存储，而这个文件的数据存储形式，他选择只在MYI文件中存储关键字和磁盘地址，然后通过索引到具体的关键字之后，通过地址去提取数据。如下图所示
2.INNODB中的存储引擎，通过物理文件观察这是否发现只有一个IBD文件，在innodb下mysql的数据和索引存储的位置是在同一文件下
在innodb中， 索引的体现形式主要核心是以主键为主， 他只有一个ibd文件。作为存储索引和数据的文件，这种好处在于，现在我只需要去维护
我们的主键索引，并不需要去维护我们的辅助索引
五、索引知识补充
1.列的离散性
看上图， 这个时候我们需要找出列的离散性高的列来作为索引， 而低的列并不推荐。
如果我们选择sex作为索引列， 那么，这个时候，模拟一组索引B+TREE结构，如下图
这个时候我们可以看到，有只有男女所生成的B+TREE 数值只有0,1两个代表，当数据量大是， 走到红框处，
这时会发现，我们选择左边也可以，右边也可以，中间也行。这时我们就会发现可选择行太多了。如果是N路的情况，
是否要判断的路数会更多？ 所以，mysql查询优化器这个时候会认为，既然要做这么多操作，可选择行这么差。
那我何不直接做全表扫描，注意：这里是因为mysql的查询优化器基于计算成本考虑会自行选择。所以有风险存在，
你写了索引相当于没写
2.最左比对原则
如果有一个字段name索引， mysql在对于索引中关键字的比对，是基于最左匹配，且不可跳过
所有数值都会被转换成unicode编码进行排序，如下图
explain select * from users where uname like 'iforce%' \G
explain select * from users where uname like '%iforce%' \G
3.联合索引
联合索引节点中关键字[name,phoneNum]
单列索引是特殊的联合索引 联合索引列选择原则
1.经常用的列优先 【最左匹配原则】
2.选择性（离散度）高的列优先【离散度高原则】
3.宽度小的列优先【最少空间原则】
本质上联合索引是一个单列索引，其转换过程如下图：
使用原则：【最左匹配原则】>【离散度高原则】 >【最少空间原则】
保证最左，离散高度，最小空间（路数越高）
案例：
经排查发现最常用的sql语句：
Select * from users where name = ? ;
Select * from users where name = ? and phoneNum = ?;
常用解决方案：
create index idx_name on users(name);
create index idx_name_phoneNum on users(name,phoneNum);
这种做法idx_name这个索引就成了冗余索引吗，
因为基于最左匹配索引，直接使用联合所以就能直接找到name上的索引键，
mysql在进行比对的时候，先会去找列的段， 然后每一段都基于最左匹配的规则，
如果匹配到了一个列，后续不在进行匹配，就是上面我们所说的最左匹配原则
4.覆盖索引
如果查询列可通过索引节点中的关键字直接返回，则该索引称之为 覆盖索引。
覆盖索引可减少数据库IO，将随机IO变为顺序IO，可提高查询性能
如果建有索引： create index idx_name_phoneNum on users(name,phoneNum);
使用：select * from users where name = ? 语句
那么需要找到name索引位置，然后到叶子节点中去提取所有数据
但是，如果使用语句：select name,phoneNum from users where name = ?
那么，mysql不会再去叶子节点中去找寻数据， 直接在索引结构中，将这个数据提取，然后返回， 提高了IO效率
六、验证前辈们的经验
前辈们是否告诫过我们mysql优化应该这样玩？
1.索引列的数据长度能少则少。
2.索引一定不是越多越好，越全越好，一定是建合适的。
3. 匹配列前缀可用到索引 like 9999%，like %9999%、like %9999用不到索引；
4. Where 条件中 not in 和 <>操作无法使用索引；
5. 匹配范围值，order by 也可用到索引；
6.多用指定列查询，只返回自己想到的数据列，少用select *； 联合索引中如果不是按照索引最左列开始查找，无法使用索引；
7.联合索引中精确匹配最左前列并范围匹配另外一列可以用到索引；
8.联合索引中如果查询中有某个列的范围查询，则其右边的所有列都无法使用索引
