MySQL为什么选择B+树存储索引
为什么加索引?
如果上面的表,我们执行SQL语句
select * from table where Col2=89;
这样就会造成全表扫描,从第一行读取到倒数第二行,然后拿到这个89这个对应的值的位置,这样就做了6次才找到对应的值,但是加上索引就不一样了,接下来介绍索引是什么?
MySQL的索引是什么:
索引是帮助MySQL高效获取数据的排好序的数据结构
索引的数据结构包括:
二叉树
红黑树
Hash表
B-Tree
索引存储方式
索引存储是按照KV方式进行存储的,key是这个索引元素,比如34,77等,value是这个索引在磁盘上面的文件地址,索引也是落地到磁盘上面的,因为数据时落在磁盘上面的,然后根据这个key对应的value去磁盘上面找到对应的值,然后输出.
数据使用索引的存储方式
这样是不是就很快了
但是二叉树这个数据结构在某些情况下并没有什么效果,比如这个col1这一列
,他是1-6的连续数据
他的二叉树结构就是如下
虽然还是二叉树,但是这个和没有索引效果是一样的
所以MySQL最终选的不是二叉树
然后第一种二叉树排除了.
然后对比一下红黑树
jdk1.8之后hashmap之前就是数组加链表存储的,假如链表非常长的时候,在hashmap里面查找元素性能也不是很好的快速查找所以在jdk1.8之后,在hashmap的底层链表被优化成红黑树,查找性能优化很高
红黑树的索引要是将1-7变成如下
红黑树也是二叉树,也叫做自平衡二叉树,二叉平衡树
但是MySQL最后之所以没有选择红黑树,因为红黑树在某些场景下并不能满足需求,因为用红黑树存储索引在某些情况下有如下问题:
1,层级太多,因为我们只有7个数据,层数即高度就这么多,如果要是很多的数据,那样不就更多了,假如树的高度是20,我们查找的元素在叶子结点,最快最快也要经过20次查找,也就要经过20次磁盘io查找
MySQL是将这个数据结构存储在磁盘上面的,假如你先存储了10个数据,然后过了几天又存储了10个数据,中间间隔了很多天,因为数据都是要写到磁道上面,这段时间间隔可能写了很多其他数据,可能都跨磁道了,这样查询起来更慢了,因为他也是都磁盘上面找的.
树的高度越低,查找速度越快,最好对这个树的高度做一下优化,即使上千万数据,也让这个树的高度小于4,这个是可能的,
因为我们比如插入一条数据,他是先在磁盘上面开辟一个空间,然后再将数据存储上去,我们就可以一次开辟多个空间,这一行存储多个节点,然后这个多个节点又能分出很多只
上图就得到了一个B树的结构,
所以就引出了B树,B树就是B-树,两个是一个东西
B树解释:
他就是上面二叉树的变种,只不过每一个节点存储了多了key和value,而不是之前的一个
MySQL底层实际上用的是B树的变种,叫B+树
B+树解释
B+树他的叶子节点才会存储这个data,这个data对应的是这个数值在磁盘上面存储的位置,即我们最上面说的那个value
B+树每一个节点从左往右是依次递增的,而且15,18是在15-20之间,叶子结点之间用指针链接.
子节点大于等于他左边的父节点,小于右边的父节点
所有叶子结点也是从左往右依次递增,MySQL维护时候也是方便维护的
B+树也叫多路(叉)二叉树,底层也是二叉树
MySQL在B+树下如何查询:
查找30为例:
1,首先将最上面的这个如15.56.77加载到内存,这是一次磁盘的IO操作,然后在内存查找
2,然后发现30是位于15.56之间,然后去他们两个之间的那个空白节点把下面第二行的地址拿到,然后将这个对应的第二行加载到内存,又是一次磁盘IO操作
3,然后发现这个30位于20和49之间,然后读这个第二行的20和49之间的地址,将对应的第三行读取到内存,第三次磁盘IO.
疑问:为什么不把所有数据都放在第一行呢?
答:假如数据量很大,几千万行数据,一次把几千万行数据直接加载到内存,那样内存大概率感触几百兆.而且一次磁盘IO撑死几M,可能就几十K,几百兆的一次磁盘IO完成不了,磁盘IO几百兆也需要几秒钟或者几十秒.
所以这个每一行每一点存储多少K的数据,MySQL给我们提供了一个默认的,16K,这个一次磁盘IO读取16K数据还是很简单的,这个值是MYSQL研发人员在多次测试的成果下给设置的默认值,单位是B
show global status like 'Innodb_page_size'
为什么MYSQL默认设置为16K?
一般索引都是用INT OR BIGINT
以bigint为例,比如这个索引15一般MySQL给他存储的是8B,然后他和56之间的空白格,这个是下一排的地址.是一个指针,索引和指针成对出现,这个一般是存储6B,MySQL给的值,所以一行16k*1024/(8+6)=1170个
叶子节点是没有这个空白区域,因为空白区域存放的是指针,他不需要指向下一位,所以没有这个指针,他的data占用的比较大,大概是1Kb左右,所以叶子节点一个是存储16个元素。
假如一个三层的B+树放满了,就是1170117016=两千两百万
所以就可能千万级别数据只需要查询三层
hash表存储方式
MySQL的索引也可以按照hash表存储方式,
MyISAM和InnoDB存储引擎：只支持BTREE索引， 也就是说默认使用BTREE，不能够更换,
但是hash索引某些存储引擎比如innodb是不支持的,除非经过特殊设置
hash表索引在MySQL用的很少
虽然用navicat在innodb和mylsam引擎下,可以选择hash索引,但是你会发现,点击保存,自动变成了Btree,如果是memory引擎,他就可以选择hash索引,memory存储引擎支持hash索引存储和btree方式
如果使用hash表存储的话,就是hash(索引值),把这个hash索引值之后的结果和磁盘地址两个做一个唯一的映射,这样看起来好像感觉执行比如下面这个SQL好像比B+更快,因为只需要对这个索引做一次hash,然后拿这个这个hash值去磁盘映射的位置找到这个对应的值即可
另外MySQL底层对hash碰撞(如果两个输入串的hash函数的值一样，则称这两个串是一个碰撞)规避得很好
比如select * from a where Col1=1
但是,假如执行的是select * from a where Col2<89 and Col2>34,这个就是B+更快乐,绝大部分场景都是范围查找吧.所以MySQL默认是B+tree,但是也可以选择hashTress
用B+树查找时候,实现范围查找就非常快了,他的叶子节点之间用指针连接起来的,而且是双向的,首尾相连的
而B树叶子结点没有指针的,
假如查找的是10-50之间数据,找到20之后,又要从根节点索引元素查找到49,不能像B+树那样直接向右取
联合索引:
这个就是把之前的一个字段转换成现在的三个字段而已,这个对比排序方式是首先按照第一个字段对比,都一样在比较第二个字段,在一样的话再比较第三个字段 。