mysql学习之B+Tree树与索引的学习

定义

索引是为了加速对表中数据行的检索而创建的一种分散存储的数据结构。


image.png

为什么要使用索引?

  1. 索引能极大的减少存储引擎需要扫描的数据量。

  2. 索引可以把随机I/O变成顺序I/O。
    mysql 数据最终都会刷到磁盘上去,刷盘分随机IO和顺序IO,两者性能相差很大,大多情况下我们会改变一下设计使mysql 的随机IO变为顺序IO来提高性能。对随机I/O和顺序I/O想深入了解的可以看这篇文章:https://blog.csdn.net/dba_waterbin/article/details/8937441

  3. 索引可以帮助我们在进行分组、排序等操作时,避免使用临时表。

B+Tree

索引的存储数据结构是使用B+树进行构建的,使用二叉树来进行存储可以加快查找的速度。在介绍B+Tree之前,先介绍下二叉平衡查找树。如图


image.png

数据在构建时是参考如下结构:


image.png

在查找数据时,如果x<10.会走P1节点的引用,数据区是具体数据的地址。这个结构是一个平衡二叉树的数据结构,查找很快,但是仍然有如下的缺点:

如果数据量很大,达到几十万。
1.数据太深了,决定了它I/O操作的次数会很大。
2.每个磁盘块保存的数据量较小。没有很好的利用操作磁盘数据I/O的特性,mysql每次读取的页数大小为16k。

再来参考下如下这种数据存储的结构(解决了以上两个问题):



类似2-3树也叫做B树,所以很多关系型数据库都采用B树的数据结构方式作为存储索引的数据。

mysql采用B+Tree的结构来进行存储。

如图:


image.png

1,B+节点关键字搜索采用闭合区间(为了往右边进行一个数据的插入,就算查到id==1,也会继续往下面走)
2,B+非叶节点不保存数据相关信息,只保存关键字和子节点的引用
3,B+关键字对应的数据保存在叶子节点中
4,B+叶子节点是顺序排列的,并且相邻节点具有顺序引用的关系(保证数据天然具有排序能力)

好处(与B树的区别):
B+树是B-树的变种(PLUS版)多路绝对平衡查找树,他拥有B-树的优势
B+树扫库、表能力更强
B+树的磁盘读写能力更强
B+树的排序能力更强
B+树的查询效率更加稳定
利用好操作磁盘数据I/O的特性

Mysql中B+树索引的体现形式

Myisam


image.png

如图,在Myisam存储引擎中,每条数据对应保存一个引用地址(物理磁盘位置的一个指针),在查询时,根据B树索引找到对应数据的地址,然后根据地址,去加载数据的内容。ID列和name列的索引是平级的。建立索引后,会生成两个文件,分别是 .MYI和 .MYD为后缀的文件。但是innodb只有一个idb文件。

Innodb


image.png

是以主键为索引来组织数据的存储,如果没有主动建立索引,则会默认建一个隐式的六位数的一个主键索引。
Innodb是数据与关键字都存储在一起的,使用的是聚集索引。那么索引一旦建立会变成下面这样组织。


image.png

查找时,先基于name,找到101,然后再通过101,找到数据。先用辅助索引找到主键索引。为什么辅助索引不用一个地址,指向数据呢?

这样设计的考量在于,一旦主键索引中的数据发生变化,迁移,不需要回过头来维护辅助索引。

聚集索引: 数据库表行中的物理顺序与键值的逻辑顺序相同。

非聚集(unclustered)索引。

定义:该索引中索引的逻辑顺序与磁盘上行的物理存储顺序不同,一个表中可以拥有多个非聚集索引.

如何解决非聚集索引的二次查询问题
复合索引(覆盖索引)
建立两列以上的索引,即可查询复合索引里的列的数据而不需要进行回表二次查询,如index(col1, col2),执行下面的语句

区别看这里: https://www.cnblogs.com/s-b-b/p/8334593.html

Innodb与Myisam的区别

image.png

Myisam引擎它的数据跟索引是分离的,而innodb的数据跟所有是放在一起的,看上图。

关于列的离散性


如图所示,在name这一列(第一列),离散型是最好的,选择性最好。而zoneDesc中,第一位是0开头的,后面是7,1,2,离散型还不够好重合的多。

最左匹配原则

对索引中关键字进行计算(对比),一定是从左往右依次进行,且不可跳过


image.png

索引的种类

单列索引与联合索引

单列索引

节点中关键字[name]

联合索引

节点中关键字[name,phoneNum]

单列索引是特殊的联合索引

联合索引列选择原则

1,经常用的列优先 【最左匹配原则】
2,选择性(离散度)高的列优先【离散度高原则】
3,宽度小的列优先【最少空间原则】

覆盖索引

如果查询列可通过索引节点中的关键字直接返回,则该索引称之为覆盖索引。
覆盖索引可减少数据库IO,将随机IO变为顺序IO,可提高查询性能

索引的使用规范

索引列的数据长度能少则少。
索引一定不是越多越好,越全越好,一定是建合适的。
匹配列前缀可用到索引 like 9999%,like %9999%、like %9999用不到索引;
Where 条件中 not in 和 <>操作无法使用索引;
匹配范围值,order by 也可用到索引;
多用指定列查询,只返回自己想到的数据列,少用select *;

最左匹配原则

联合索引中如果不是按照索引最左列开始查找,无法使用索引;
联合索引中精确匹配最左前列并范围匹配另外一列可以用到索引;
联合索引中如果查询中有某个列的范围查询,则其右边的所有列都无法使用索引;

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 214,444评论 6 496
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,421评论 3 389
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 160,036评论 0 349
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,363评论 1 288
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,460评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,502评论 1 292
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,511评论 3 412
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,280评论 0 270
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,736评论 1 307
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,014评论 2 328
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,190评论 1 342
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,848评论 5 338
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,531评论 3 322
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,159评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,411评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,067评论 2 365
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,078评论 2 352

推荐阅读更多精彩内容