索引.png

我们为什么要使用索引

不使用索引，则意味着在查询数据的时候要进行全表扫码；在单表的数据达到近千万时，检索效率可想而知，即使数据没有千万，在业务复杂的场景下，如果没有使用索引，效率也会非常低

什么的信息能成为索引呢

区分度越高的数据列越适合做索引。想想日常开发中，基于 Innodb 创建的表基本都会使用自增的ID作为主键，这个主键就是我们的主键索引，它全表唯一，通过它查找数据，效率最高，具体原因文章后面会分析

索引的数据结构

MySQL 的 MyISAM、Innodb 存储引擎底层都是使用的 B+ 树，具体原因看另一篇文章【数据库存储依赖的数据结构】

密集索引与稀疏索引

从物理存储的角度来分析一下索引，并且着重分析我们日常开发使用的 MySQL

密集索引

密集索引文件中每个搜索码值都对应一个索引值
叶子节点不仅存储了键值，还存储了当前列所在行的所有列值，由于密集索引决定了表的物理排列顺序，而表的物理排列顺序只能有一种，因此一张表中只能有一个密集索引

稀疏索引

稀疏索引文件只为索引码的某些值建立索引项
叶子节点仅存储当前键值信息及当前行的地址或者行的主键信息，在检索相应行信息的时候，需要通过地址或者主键信息进行二次查找

MySQL 索引分析

Innodb 存储引擎

Innodb 必须并且有且仅有一个密集索引，那么这个密集索引的选择规则是怎样的呢？

1.如果表中含有主键，则使用主键作为密集索引
2.在没有主键的情况下，会选取表中第一个唯一非空索引作为密集索引
3.上面两者都满足时，Innodb 会自身生成一个唯一非空索引作为密集索引【6字节、并且是自增的】

Innodb 为什么必须要有一个主键索引呢？
因为 Innodb 的数据和索引是存储在同一个文件当中（.ibd文件中，后面的文章会分析），并且数据是存储在主键索引树的叶子节点上，而且主键使用了密集索引【聚簇索引】，因此在检索的时候，在加载叶子节点的主键进入内存的同时，也加载了对应的数据。如下图中，通过id = 14查询主键的时候，则会按照 B+ 树的检索算法，即可找到对应的叶子节点，并且也获得了对应的行数据.
即 Innodb 的存储结构决定了它必须要有一个主键索引.
Innodb 其他索引是基于稀疏索引实现，即每次通过辅助索引检索数据时，需要先找到对应的主键索引，然后通过主键索引检索数据行，这也就是 Innodb 存储引擎下，通过主键 Id 检索数据的效率最高

MyISAM 存储引擎

而 MyISAM 基于稀疏索引【非聚簇索引】实现。MyISAM 的数据文件和索引文件是分开存储的，具体的文件格式可以参考我的另一篇文章【存储引擎——MyISAM】，所以无论是通过主键索引，还是其他索引检索数据的时候，都需要通过两次查找的方式检索数据，即第一次找到对应的键及对应行的地址，第二次检索数据；对于表数据来说，主键索引和辅助键索引没有任何区别，由于索引树是独立的，因此通过辅助键检索无需访问主键的索引树
MyISAM 的索引也是基于 B+ 树实现。

InnoDB 和 MyIsam.png