索引的数据结构

索引的数据结构

二叉树：当索引为单调递增时，二叉树就变成了链表，查找效率较低

红黑树：当数量很大的时候，树的高度会很高，如果数据在叶子节点，红黑树的性能就不高了。

存储横向的元素越多，树的高度就降低了—> B-Tree

把所有的索引全都放在叶子节点，提取第一个节点形成冗余索引，这个树从左到右是排好序的

当B+树高度为3，可以存放的数据达到2千多万(1170* 1170 *16)每页可以存储16KB，大概可以存放1170个节点和下个磁盘的存放位置。

被查找的数据会被加载到内存，如果长时间的查找，可能每个数据都被查找加载到内存，那内存满了，怎么办？

针对缓存池设置的算法LRU（最近最少使用）淘汰一些很久没有使用的数据缓存

MylSAM存储引擎索引实现

数据表默认存在根目录下的data里面

一张表对应三个文件，一个存框架，一个存索引，一个存数据

索引和数据分开存储—非聚集存储

叶子节点存放的时磁盘位置

InnoDB存储引擎

一张表对应两个文件，一个存放表框架，一个存储索引和数据

索引和数据存放在一起—聚集索引

叶子节点存放索引

聚集存储查找效率大于非聚集的（因为索引和数据不在一个文件）

主键索引和普通索引（叶子节点存放的是索引所在行的主键）存放不一样，

为什么表要设置主键，并且推荐使用整形自增的主键？

建主键？

用B+树用主键来维护这些数据，没有主键mysql会去找一列没有重复的数，加一个唯一索引，维护B=树的数据，如果没有找到，他会自己创建一个隐藏列，去维护这些数据创建B+树

整型？

查找比对，整型比大小快，比UUID快

自增？

如果维护的自增只需要在后面加，而不至于导致树的分裂，调整。

mysql底层时排好序的，为了支持范围查找

hash没办法查找范围查找（查找大于30的…）

B+树里面有双向指针，可以很好的支持范围查找

B+树和B树的区别？

B树叶子节点没有双向指针，不能很好的支持双向查找，且没有冗余节点，每个节点下面都有数据

存储相同数量的索引，B树会更高，因为决定树高度是非叶子结点，非叶子结点横向更多的话，叶子节点存储的索引就越多。

联合索引

先按第一个排序，其次第二个，最后第三个

没有跳过前面的

为什么第一条走了索引，第二条没走？

因为没有name，age索引并没有排好序

如果用name和position索引去查找，会走name索引，position索引不会走，因为跳过了age，position没有排好序。

总结

1、为什么mysql索引使用B+树，而不是用其他数据结构（hash, b树，红黑树，二叉树）？

先说二叉树，现在主键索引大部分都是整型自增的，如果使用二叉树，树的结构最后会变成链表，线性排列，这样查找效率比较低。

再说以下红黑树，因为红黑树是一颗二叉查找树，它树的高度会随着数据的增加而变大，当数据量比较大的时候，而我们要查找的数据位于叶子节点，这样的效率也比较低了。

那为什么用b+树而用b树呢？

B 树与 B+ 树的最大区别就是，B 树可以在非叶结点中存储数据，这也导致在查询连续数据时可能会带来更多的随机 I/O。但是 B+ 树的所有数据其实都存储在叶子节点中，而且B+树的叶子节点有双向指针连接，查找某个范围的数据时，能够减少顺序遍历时产生的额外随机 I/O

不用hash是因为它没办法支持某个范围的查找

2、为什么b+树三层能存储两千万的数据？

B+树的非叶子结点不存储数据，存储的是冗余索引和下一个磁盘存放的位置，我们假设主键ID为bigint类型，长度为8字节，而指针大小在InnoDB源码中设置为6字节，这样一共14字节。而InnoDB种一页就可以存储16kb，这样一计算，一层就可以存储1170对索引与指针，假设一行记录的数据大小为1kb，那么叶子节点可以存储16个，这样三层的话就是1170* 1170 *16约为2190多万

3、为什么表要设置主键，并且推荐使用整形自增的主键？

因为B+树用主键来维护这些数据，如果没有主键mysql会去找一列没有重复的数，加一个唯一索引，维护B+树，但是如果没有找到，他会自己创建一个隐藏列，去维护这些数据创建B+树。这样就增加了mysql的压力。

而为什么要设置为整型呢？

如果不设置为整型而设置为UUID，那么当去查找的时候UUID的比对速度慢于整型的对比速度，因为一个字符一个字符的对比 。

维护自增是为了每次数据的添加就直接再后面尾部完成，树不会产生分裂和调整