MySQL索引为什么用B+树

一、InnoDB 一棵 B+ 树可以存放多少行数据

约 2 千万。为什么?这是可以算出来的,要搞清楚这个问题,先从 InnoDB 索引数据结构、数据组织方式说起。

计算机在存储数据的时候,有最小存储单元,这就好比今天进行现金的流通最小单位是一毛。在计算机中磁盘存储数据最小单元是扇区,一个扇区的大小是 512 字节,而文件系统(例如 XFS/EXT4)的最小单元是块,一个块的大小是 4K。InnoDB 存储引擎也有自己的最小储存单元——页(Page),一个页的大小是 16K。

文件系统中一个文件大小只有 1 个字节,但不得不占磁盘上 4KB 的空间。

InnoDB 的所有数据文件(后缀为 ibd 的文件)大小始终都是 16384(16K)的整数倍。

磁盘扇区、文件系统、InnoDB 存储引擎都有各自的最小存储单元。

在 MySQL 中 InnoDB 页的大小默认是 16K,当然也可以通过参数设置:

mysql> show variables like 'innodb_page_size'; 
+------------------+-------+ 
| Variable_name | Value | 
+------------------+-------+ 
| innodb_page_size | 16384 | 
+------------------+-------+ 
1 row in set (0.00 sec) 

数据表中的数据都是存储在页中的,所以一个页中能存储多少行数据呢?假设一行数据的大小是 1K,那么一个页可以存放 16 行这样的数据。如果数据库只按这样的方式存储,那么如何查找数据就成为一个问题。因为不知道要查找的数据存在哪个页中,也不可能把所有的页遍历一遍,那样太慢了。所以用 B+ 树的方式组织这些数据,如下图所示:

先将数据记录按主键进行排序,分别存放在不同的页中(为了便于理解这里一个页中只存放 3 条记录,实际情况可以存放很多)。除了存放数据的页以外,还有存放键值+指针的页,如图中 page number=3 的页,该页存放键值和指向数据页的指针,这样的页由 N 个键值+指针组成。当然它也是排好序的。这样的数据组织形式,称为索引组织表。现在来看下,要查找一条数据,怎么查?如:

select * from user where id=5;

这里 id 是主键,通过这棵 B+ 树来查找,首先找到根页,你怎么知道 user 表的根页在哪呢?

其实每张表的根页位置在表空间文件中是固定的,即 page number=3 的页。找到根页后通过二分查找法,定位到 id=5 的数据应该在指针 P5 指向的页中,那么进一步去 page number=5 的页中查找,同样通过二分查询法即可找到 id=5 的记录:

5 zhao2 27 

小结:

  • InnoDB 存储引擎的最小存储单元是页,页可以用于存放数据也可以用于存放键值+指针,在 B+ 树中叶子节点存放数据,非叶子节点存放键值+指针。
  • 索引组织表通过非叶子节点的二分查找法以及指针确定数据在哪个页中,进而在去数据页中查找到需要的数据。

那么回到开始的问题,通常一棵B+树可以存放多少行数据?

这里先假设 B+ 树高为 2,即存在一个根节点和若干个叶子节点,那么这棵 B+ 树的存放总记录数为:根节点指针数*单个叶子节点记录行数。单个叶子节点(页)中的记录数为 16K/1K=16。(这里假设一行记录的数据大小为 1K,实际上现在很多互联网业务数据记录大小通常就是 1K 左右)。

那么现在需要计算出非叶子节点能存放多少指针?其实这也很好算,假设主键 ID 为 bigint 类型,长度为 8 字节,而指针大小在 InnoDB 源码中设置为 6 字节,这样一共 14 字节。一个页中能存放多少这样的单元,其实就代表有多少指针,即 16384/14=1170。由此可以算出一棵高度为 2 的 B+ 树,能存放1170*16=18720条这样的数据记录。同理一个高度为 3 的 B+ 树可以存放:1170*1170*16=21902400条这样的记录。所以 InnoDB 中 B+ 树高度一般为 1-3 层,它就能满足千万级的数据存储。

在查找数据时一次页的查找代表一次 IO,所以通过主键索引查询通常只需要 1-3 次 IO 操作即可查找到数据。

二、怎么得到 InnoDB 主键索引 B+ 树的高度

在 InnoDB 的表空间文件中,约定 page number 为 3 的代表主键索引的根页,而在根页偏移量为 64 的地方存放了该 B+ 树的 page level。

如果 page level 为 1,树高为 2,page level 为 2,则树高为 3。即 B+ 树的高度=page level+1。下面将从实际环境中尝试找到这个 page level。

在实际操作之前,你可以通过 InnoDB 元数据表确认主键索引根页的 page number 为 3,你也可以从《InnoDB 存储引擎》这本书中得到确认:

SELECT 
b.name, a.name, index_id, type, a.space, a.PAGE_NO 
FROM 
information_schema.INNODB_SYS_INDEXES a, 
information_schema.INNODB_SYS_TABLES b 
WHERE 
a.table_id = b.table_id AND a.space <> 0; 

执行结果:

可以看出数据库 dbt3 下的 customer 表、lineitem 表主键索引根页的 page number 均为 3,而其他的二级索引 page number 为 4。

下面对数据库表空间文件做想相关的解析:

因为主键索引 B+ 树的根页在整个表空间文件中的第 3 个页开始,所以可以算出它在文件中的偏移量:16384*3=49152(16384 为页大小)

另外根据《InnoDB 存储引擎》中描述在根页的 64 偏移量位置前 2 个字节,保存了 page level 的值。

因此想要的 page level 的值在整个文件中的偏移量为:16384*3+64=49152+64=49216,前 2 个字节中。

接下来用 hexdump 工具,查看表空间文件指定偏移量上的数据:

  • linetem 表的 page level 为 2,B+ 树高度为page level+1=3。
  • region 表的 page level 为 0,B+ 树高度为 page level+1=1。
  • customer 表的 page level 为 2,B+ 树高度为 page level+1=3。

这三张表的数据量如下:

三、总结

lineitem 表的数据行数为 600 多万,B+ 树高度为 3,customer 表数据行数只有 15 万,B+ 树高度也为 3。可以看出尽管数据量差异较大,这两个表树的高度都是 3。换句话说这两个表通过索引查询效率并没有太大差异,因为都只需要做 3 次 IO。

那么如果有一张表行数是一千万,那么它的 B+ 树高度依旧是 3,查询效率仍然不会相差太大。region 表只有 5 行数据,当然它的 B+ 树高度为 1。

为什么 MySQL 的索引要使用 B+ 树而不是其他树形结构,比如 B 树?因为 B 树不管叶子节点还是非叶子节点,都会保存数据,这样导致在非叶子节点中能保存的指针数量变少(有些资料也称为扇出)。指针少的情况下要保存大量数据,只能增加树的高度,导致 IO 操作变多,查询性能变低。

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