MySQL优化及索引的方法

索引简单介绍

索引的本质：

MySQL索引或者说其他关系型数据库的索引的本质就只有一句话，以空间换时间。

索引的作用：

索引关系型数据库为了加速对表中行数据检索的（磁盘存储的）数据结构

索引的分类

数据结构上面的分类：

HASH 索引

等值匹配效率高
不支持范围查找

树形索引

二叉树，递归二分查找法，左小右大
平衡二叉树，二叉树到平衡二叉树，主要原因是左旋右旋
缺点1，IO次数过多
缺点2，IO利用率不高，IO饱和度

多路平衡查找树（B-Tree）

特点，大大的减少了树的高度

B+树

特点，采用左闭合的比较方式
根节点支节点没有数据区，只有叶子结点才包含数据区（说白了就是即便在根节点和子节点已经定位到，因为没有数据区的原因也不会停留，会一直找到叶子结点为止。）

当我们搜索13这条数据时，在根节点和子节点都能定位，但是一直会找到叶子结点。

二叉树平衡二叉树，B树对比:

如图显示如果是自增主键情况下：
二叉树显然不适合做关系型数据库索引（和全表扫描没什么区别）。
平衡二叉树呢，虽然解决了这种情况，但是同样会导致这棵树，又瘦又高，这同样会造成上文所提到查询IO次数过多以及IO利用率不高。
B树呢，显然已经解决了这两个问题，所以下文来解释，为什么在这种情况下MySQL还用了B+树，又做了那些增强。

B树和B+树比较:

B+树在B树上面的优化:

IO效率更高（B树每个节点都会保留数据区，而B+树则不会，假设我们查询一条数据要遍历三层，那么显然B+树查询中IO消耗更小）

范围查找效率更高（如图，B+树已经形成了一个天然链表形式，只需要根据最结尾的链式结构查找）

基于索引的数据扫描效率更高。

索引类型的分类

索引类型可分为两类:

主键索引
辅佐索引(二级索引)

唯一性索引
复合索引
普通索引
覆盖索引

虽然主键索引性能相对最佳，但通常在SQL优化中，我们会在辅助索引上进行改进和补充。

B+树在储存引擎层面落地

我们创建两个表分别为test_innodb（采用InnoDB作为储存引擎）test_myisam（采用MyISAM作为储存引擎）下图是两张表磁盘落地的相关文件，这两个储存引擎在B+树磁盘落地式截然不同的。

B+树在MyISAM落地：

*.frm文件是表格骨架文件比如这个表中的id字段name字段是什么类型的存储在这里
*.MYD（D=data）则储存数据
*.MYI （I=index）则储存索引

比如现在执行如下sql语句，那么在MyISAM中他就是先在test_myisam.MYI中查找到103然后拿到0x194281这个地址然后再去test_myisam.MYD中找到这个数据返回。

SELECT id,name from test_myisam where id =103

如果test_myisam表中，id为主键索引，name也是一个索引，那么在test_myisam.MYI中则会有两个平级的B+树，这也导致MyISAM引擎中主键索引和二级索引是没有主次之分的，是平级关系。因为这种机制在MyISAM引擎中，有可能使用多个索引，在InnoDB中则不会出现这种情况。

B+树在InnoDB落地：

InnoDB不像MyISAM来独立一个MYD 文件来存储数据，它的数据直接存储在叶子结点关键字对应的数据区在这保存这一个id列所有行的详细记录。
InnoDB 主键索引和辅助索引关系

我们现在执行如下SQL语句,他会先去找辅助索引，然后找到辅助索引下101的主键，再去回表（二次扫描）根据主键索引查询103这条数据将其返回。

SELECT id,name from test_myisam where name ='zhangsan'

这里就有一个问题了，为什么不像MyISAM在辅助索引下直接记录磁盘地址，而是要多此一举再去回表扫描主键索引，这个问题在下面相关面试题中回答，记一下这个问题是这里来的。