索引是帮助Mysql高效的获取数据的排好序的数据结构;
索引的数据结构:
二叉树
红黑树
Hash表
B-Tree
以上图为例:若使用Col2作为索引,则可以根据二叉排序树更快地寻找的数据;
但是若以Col1为索引(类似于自增/减的索引)则:
此时的树状结构类似于链表,因此也并没有优化数据的查询速度,和没有创建索引逐行查找没有本质上的区别;
此时若采用红黑树结构:
由图可见红黑树也是一种二叉平衡树;
此时虽然红黑树比二叉树有一些优化,但是当数据到达一定的量级(海量数据),红黑树的高度还是很高,效率仍是很低;(数据量越大,效率越低)
由红黑树的不足得出的思考改进:
可以在每个节点存放多个索引,则可以很好地降低树的高度;
B-树:
查找过程:每次一次性地将某个节点load到RAM中进行比较(更快);
当然一次load不能load过多的数据,Mysql规定在16KB左右;
B+树(多叉平衡树):
两者的比较:
1.B+树上非叶子节点上没有data,B树有;
2.B+树中每两个叶子节点之间有双向指针,B树没有;
问题1:为什么要有冗余索引,且把data元素从非叶子节点移到叶子节点呢?
将data元素移到叶子节点可以保证每个非叶子节点上横向可以存储更多的索引元素,也就意味着每个节点分叉也就更多了,因此可以保证树的深度最低;
(经大致估算,2千多万行的数据,采用B+树,树的高度为3)
问题2:为什么绝大多数情况不适用Hash查找呢?
首先需要提Hash查找,实际上Hash查找的速度比使用B+树的速度更快,但是为什么绝大多数情况不适用Hash查找呢?
看这种情况:
Select * from t where t.col1 >16;
若使用范围查找,则Hash索引并不能很好的支持范围查找;
因此绝大多数使用B+树的结构;
问题3:为什么B+树索引中的叶子节点之间有指针呢?
若此时想查找col1>20的元素,则在找到20之后,依次依靠指针向右获取所要的数据,极大地提高了范围查找的效率,因为叶子节点之间需要双向的指针;
(采用B树的话则需要重新返回根节点,再去查询,重复这个过程,效率很低)