mysql数据库索引底层原理实现

目录

1.首先简单说下mysql的两大常用存储引擎：

2.到底什么是索引？该如何理解？为什么需要它？

---

 

1.首先简单说下mysql的两大常用存储引擎：

InnoDB：聚集性索引

MyISAM：非聚集性索引

聚集性与非聚集性索引如何理解呢？

简单来说就是：

聚集性索引：把数据一起聚集到了索引上面来了。

非聚集性索引：没有把数据聚集到索引上面，并且索引上面的叶子节点只是存储了数据的物理磁盘上的地址。

你去你的mysql安装目录下看两个数据库的文件就会发现，MyiSam的文件比InnoDB的多出了一个文件：MYI （存索引的文件）

为什么这样做呢 ？当然是适应不同业务场景，通常InnoDB适用于大多数的业务场景。

 

2.到底什么是索引？该如何理解？为什么需要它？

回过头来，我们再看看索引。为什么需要索引？当然是需要提高数据检索的速度了。

通常听别人解释，索引就类似字典的目录，能快速的查找定位到想找的页数，我们切换到数据库，比如我们表A的主键索引ID列，作为了索引列，显然，id列是顺序排序的，我们查找表是顺序排序，而把索引拿出去了，不一样还是顺序排序吗？哪里就提高了呢？

首先，我们是会吧索引列load到内存中来检索，速度当然提高了，所以都是key-value（key=索引值，value=该值所在的物理磁盘地址行）存储，所以检索到了key之后，就能快速定位到行了。

显然上面，问题，顺序排序的情况，并不会快很多，所以想到对于数据结构的改造，通常使用的数据结构有如下些：

二叉树：说白了，小的在左边，大的在右边，如图：（缺点：顺序排序的时候的数据导致节点过深，再由于查询是由根节点开始，所以查询会比较慢）

红黑树（Red Black Tree） 是一种自平衡二叉查找树：

红黑树：比二叉树好一点的红黑树，能在比较深的时候，自动平衡，从而变短节点和深度。

B-tree，B数：比上面的两种更高级一点...略

直接说mysql底层使用实现的树，B+ tree:

 Myisam 中的索引和数据分别存放在不同的文件，所以在索引树中的叶子节点中存的数据是该索引对应的数据记录的地址，由于数据与索引不在一起，所以 Myisam 是非聚簇索引:

 

InnoDB 是以 ID 为索引的数据存储。

采用 InnoDB 引擎的数据存储文件有两个，一个定义文件，一个是数据文件。

InnoDB 通过 B+Tree 结构对 ID 建索引，然后在叶子节点中存储记录:

 

有没有注意到InnoDB的叶子节点的箭头？

箭头何意？

因为 这种数据结构 从左至右始终是顺序大小，箭头则可以当做直接查询右边，对于返回查找很方便快捷。

比如，

Hash查找不比B+tree快很多？

hash数据结构存储的数据：把一条数据扔hash里面，通过计算hash值后能快速定位到这个值的地方，但是，如果是范围查找呢，是不是就没有办法了，此时，B+tree呢对于范围查找就很快读便捷，所以综合考虑还是使用B+tree，适用更多业务场景。

同样 如果是B-tree，没有这个箭头，同样每次查找，一次查找完成之后，下次查找又得从根节点开始查询，相对于B+tree也会慢一些。

上图的箭头，B+tree：对于范围查找，只需要右边或者左边一个范围的查找很快速编辑，而hash做范围查询显然不行，或者B-tree做范围，每次又得从根节点开始来，或者UUID的注解做范围查找，显然需要字符串转码后再进行比较，显然没有数值自增来的便捷。

所以，通常推荐使用：InnoDB，因为他本身包括数据表结构就是一个B+tree，同时为了能更好的维护索引以及数据，推荐使用ID的自增。

 

手码得有点乱，见谅、包涵，这是自己的理解！改天再来锊锊详细！多谢！