菜单

mysql 为何用b+ 树

2019年10月19日 - sqlite

1、B+树基本概念

原因就是为了减少磁盘io次数,因为b+树所有最终的子节点都能在叶子节点里找见,
所以非叶子节点只需要存`索引范围和指向下一级索引(或者叶子节点)的地址` 就行了,
不需要存整行的数据,所以占用空间非常小,直到找到叶子节点才加载进来整行的数据。

B树非叶子节点也会存数据,所以不适合mysql(以后研究下mongo为啥用b树 再补充)

  B+树的言语定义相比复杂,简单的讲是为磁盘存取设计的平衡二叉树

B+树适同盟为数据库的根底结构,完全部都是因为Computer的内部存款和储蓄器-固态硬盘两层存储结构。内部存款和储蓄器能够做到神速的放肆访谈(随机访谈即给出大肆三个地点,供给重回这一个地点存款和储蓄的数据)可是体积十分小。而硬盘的随便拜谒要透过机械动作(1磁头移动
2盘片转动),访问作用比内部存款和储蓄器低多少个数据级,可是硬盘体积很大。规范的数据水库蓄水体积量大大超越可用内部存储器大小,那就调节了在B+树中找找一条数据很恐怕要重视三回磁盘IO操作来形成。如下图所示:平日向下读取三个节点的动作恐怕会是贰次磁盘IO操作,可是非叶节点日常会在起来阶段载入内部存款和储蓄器以加速访谈速度。同一时候为增高在节点间横向遍历速度,真实数据库中恐怕会将图浅紫蓝色的CPU计算/内部存款和储蓄器读取优化成二叉寻找树(InnoDB中的page
directory机制)。

图片 1

图片 2

  英特网优异图,深米黄p1 p2
p3代表指针,金棕的意味磁盘,里面包涵数据项,第一层17,35,p1就意味着小于17的,p2就表示17-35里面包车型大巴,p3就象征大于35的,可是供给静心的是,第三层才是真正的多少,17、35都不是真正数据,只是用来划分数据的!

image

2、为啥选择B+树

实际数据库中的B+树应该是十三分扁平的,能够经过向表中逐个插入丰富数量的办法来验证InnoDB中的B+树到底有多扁平。我们因此如下图的CREATE语句建构叁个独有轻松字段的测验表,然后不断拉长数据来填充那么些表。通过下图的总结数据(来源见参谋文献1)能够分析出多少个直观的结论,那多少个结论宏观的显现了数据CurryB+树的规范化。

  B+树有何实惠大家非要使用它吗?那就先要来看看mysql的目录

1
每种叶子节点存款和储蓄了468行数据,每一个非叶子节点存款和储蓄了大要上1200个键值,那是一棵平衡的1200路寻觅树!

 

2
对此一个22.1G体积的表,也只需求中度为3的B+树就会累积了,这么些容积大约能满意众多用到的内需了。借使把高度叠合到4,则B+树的积存容积立时增大到25.9T之巨!

  2.1mysql索引

3
对于多个22.1G体积的表,B+树的万丈是3,要是要把非叶节点全体加载到内部存款和储蓄器也只需求简单18.8M的内存(怎样得出的那个结论?因为对于中度为2的树,1203个叶子节点也只要求18.8M空中,而22.1G从良表的莫斯中国科学技术大学学是3,非叶节点1204个。同期我们假设叶子节点的尺码是出乎非叶节点的,因为叶子节点存款和储蓄了行数据而非叶节点唯有键和一丢丢数码。),只行使那样少的内部存款和储蓄器就足以保证只供给贰遍磁盘IO操作就招来出所需的数据,成效是那几个之高的。

    试想一下在mysql中有200万条数据,在一向不树立目录的状态下,会全部进展围观读取,这一个时刻消耗是十三分焦灼的,而对此大型一点的网址以来,到达那些数据量很轻易,不容许那样去规划

图片 3

    在我们创立数量库表的时候,我们都知情一个事物叫做主键,平日来说数据库会自动在主键上创制索引,那称之为主键索引,来看看索引的分类吧

image

    a.主键索引:int优于varchar

    b.普通索引(INDEX):最基本的目录,未有限定,加速查找

    c.独一索引(UNUQUE):听名字就精晓,须求全部类的值是并世无两的,不过允许有空值

    d.组合索引:

1 CREATE INDEX name_age_address_Index ON `student`(`name`, `age`, `address`);

    在那处其实包括多少个目录,说起组合索引,必定要讲最左前缀原则

 


    最左前缀原则:

      小编们未来创设了索引x,y,z,Index:(x,y,z),只会走x,xy,xyz的询问,比如:

1 select * from table where x='1'
2 select * from table where x='1' and b='1'
3 select * from table where x='1' and b='1' and c='1'

      假使是x,z,就只会走x,注意一种特殊景况,select * from table
where x=’1′ and y>’1′ and
z=’1’,这里只会走xy,因为在经历xy的筛选后,z不能够担保是平稳的,可索引是平稳的,因而不会走z


 

    e.全文索引(FULLTEXT):用于寻觅内容相当长的文章之类的很好用,假使创制普通的目录,在遇见
like=’%xxx%’这种意况索引会失效

1 ALTER TABLE tablename ADD FULLTEXT(col1, col2)
2 SLECT * FROM tablename WHERE MATCH(col1, col2) AGAINST(‘x′, ‘y′, ‘z′)

    那样就可以将col1和col2里面包罗x,y,z的记录整个抽取来了

    

    索引的删减:DORP INDEX IndexName ON `TableName`

  

    索引的得失:

      1、在数据量非常庞大的时候,创建目录有扶持大家增强查询功用

      2、在操作表的时候,维护索引会扩大额外成本

      3、不泛滥使用索引,成立多了目录文件会膨胀极快

 

  2.2B+树的亮点

    摸底上边的模子后,试想一下,200W条数据,借使没有建设构造目录,集会场全部张开围观,B+树仅仅用三层结构得以象征上百万的数码,只要求三回I/O!那进步是真的传奇人物啊!

    因为B+树是平衡二叉树,在持续的加多多少的时候,为了维持平衡或者供给做大批量的拆分操作,因而提供了旋转的效果与利益,不通晓旋转提出去补一下树的基础知识

    B+树插入动画(来自https://www.cnblogs.com/vincently/p/4526560.html)

图片 4

3、索引优化

  1、最好左前缀原则

  2、不要在目录的列上做操作

  3、like会使索引失效产生全表扫描

  4、字符串不加单引号会招致索引战败

  5、收缩使用select *

图片 5

  参照这里,写的很好 
 https://www.cnblogs.com/zhaobingqing/p/7071331.html

 

总结:

  sql语句怎么用,未有规定必得怎么查,对于数据量小,有时候无需新创造目录,依照早晚的实际景况来思量

    

 

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图