mysql索引 b+树

发布时间:2019-03-25  栏目:MyBatis  评论:0 Comments

一 、B+树基本概念

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

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

  B+树的语言定义相比复杂,一句话来说是为磁盘存取设计的平衡二叉树

B+树适合当作数据库的底蕴结构,完全是因为电脑的内部存储器-机械硬盘两层存款和储蓄结构。内部存款和储蓄器能够成功高效的轻易走访(随机走访即给出任意2个地点,必要重临这些地点存款和储蓄的数额)不过体积较小。而硬盘的人身自由访问要通过机械动作(1磁头移动
2盘片转动),访问功用比内部存款和储蓄器低多少个数据级,但是硬盘容积较大。典型的数据水库蓄水容积量大大当先可用内部存款和储蓄器大小,那就控制了在B+树中找寻一条数据非常大概要依赖一回磁盘IO操作来实现。如下图所示:平日向下读取一个节点的动作大概会是二遍磁盘IO操作,不过非叶节点常常会在开始阶段载入内部存款和储蓄器以加速访问速度。同时为增强在节点间横向遍历速度,真实数据库中可能会将图嫩清水蓝的CPU计算/内部存款和储蓄器读取优化成二叉搜索树(InnoDB中的page
directory机制)。

图片 1

图片 2

  网上经典图,粉红色p1 p2
p3代表指针,黄绿的意味磁盘,里面含有数据项,第②层17,35,p1就象征小于17的,p2就代表17-35之间的,p3就意味着大于35的,然而要求专注的是,第2层才是实际的数量,1⑦ 、35都不是实在数据,只是用来划分数据的!

image

② 、为何选择B+树

忠实数据库中的B+树应该是杰出扁平的,能够因而向表中逐条插入丰富数量的方法来验证InnoDB中的B+树到底有多扁平。大家经过如下图的CREATE语句建立三个只有大致字段的测试表,然后不断丰硕数据来填充这些表。通过下图的总结数据(来源见参考文献1)能够分析出多少个直观的下结论,那多少个结论宏观的变现了数据CurryB+树的尺度。

  B+树有哪些利益大家非要使用它呢?这就先要来探视mysql的目录

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

 

2
对此1个22.1G体量的表,也只须要中度为3的B+树就能积存了,那个体积大致能满意广大运用的内需了。倘诺把中度叠加到4,则B+树的贮存体积立时增大到25.9T之巨!

  2.1mysql索引

3
对于三个22.1G体量的表,B+树的中度是3,假如要把非叶节点全部加载到内部存款和储蓄器也只供给简单18.8M的内部存款和储蓄器(怎么样得出的那个结论?因为对当中度为2的树,1203个叶子节点也只须要18.8M空间,而22.1G从良表的万丈是3,非叶节点1205个。同时我们假若叶子节点的尺码是凌驾非叶节点的,因为叶子节点存储了行数据而非叶节点唯有键和少量数码。),只行使那样少的内部存款和储蓄器就足以确认保障只须求三遍磁盘IO操作就寻找出所需的多寡,功效是老大之高的。

    试想一下在mysql中有200万条数据,在并未树立目录的状态下,会全部拓展围观读取,这么些小时消耗是丰盛恐惧的,而对于大型一点的网站以来,达到这一个数据量很简单,相当的小概这么去设计

图片 3

    在大家创设数量库表的时候,大家都掌握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的笔录整个取出来了

    

    索引的去除:DO瑞虎P INDEX IndexName ON `TableName`

  

    索引的优缺点:

      壹 、在数据量尤其粗大的时候,建立目录有助于大家增强查询作用

      ② 、在操作表的时候,维护索引会增添额外开销

      ③ 、不泛滥使用索引,创立多了目录文件会膨胀一点也不慢

 

  2.2B+树的独到之处

    打探上边的模型后,试想一下,200W条数据,假若尚未创立目录,聚会场全部开始展览围观,B+树仅仅用三层组织能够表示上百万的多少,只供给三回I/O!这进步是真的伟人啊!

    因为B+树是平衡二叉树,在持续的充实数量的时候,为了保持平衡大概须求做多量的拆分操作,因而提供了旋转的意义,不清楚旋转提议去补一下树的基础知识

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

图片 4

三 、索引优化

  壹 、最好左前缀原则

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

  三 、like会使索引失效变成全表扫描

  ④ 、字符串不加单引号会促成索引退步

  伍 、缩短使用select *

图片 5

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

 

总结:

  sql语句怎么用,没有规定必须怎么查,对于数据量小,有时候不须要新建立目录,依照早晚的骨子里情形来设想

    

 

留下评论

网站地图xml地图