上一篇文章《MySQL索引为什么要用B+树》讲了MySQL为什么选择用B+树来作为底层存储结构,提了两个知识点:
为进一步知其所以然,今天来聊聊B+树索引在物理磁盘上是怎么设计存储的。
众所周知,MySQL的数据实际是存储在文件中,而磁盘IO的查找速度是要远小于内存速度的,所以减少磁盘IO的次数能很大程度的提高MySQL性能。
先温习下知识点:磁盘IO时间 = 寻道 + 磁盘旋转 + 数据传输时间
从磁盘读取数据时,系统会将逻辑地址发给磁盘,磁盘将逻辑地址转换为物理地址(哪个磁道,哪个扇区)。 磁头进行机械运动,先找到相应磁道,再找该磁道的对应扇区,扇区是磁盘的最小存储单元(见图1-1)。
机械硬盘的连续读写性能很好,但随机读写性能很差。
kafka的特点,以后有机会的话再讲一讲)随机读写时,磁头需要不停的移动,时间都浪费在了磁头寻址上。 而在实际的磁盘存储里,是很少顺序存储的,因为这样的维护成本会很高。
知道磁盘IO的性能了吧,接下来看看MySQL是如何根据这种情况来设计索引的物理存储,以下内容以InnoDB引擎为例,MyISAM略有不同,后面再讲。
假设我们有一张这样的表,表中有如图2-0的数据
CREATE TABLE `user` ( `ID` bigint(11) NOT NULL AUTO_INCREMENT, `NAME` varchar(20), PRIMARY KEY (`ID`), KEY `idx_name` (`NAME`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 复制代码
每个InnoDB表都有一个称为聚集索引的特殊索引,该索引是按照表的主键构造的一棵B+树。
根据示例数据构建如图2-1所示聚集索引:
这里只进行了两次IO,实际上,每个磁盘块大小为4K,3层的B+树可以表示上百万的数据,也就是每次查找只需要3次IO,所以索引对性能的提高将是巨大的。
每张InnoDB表有且只有一个聚集索引,那它是怎么选择索引的呢?
PRIMARY KEY来作为聚集索引。PRIMARY KEY,将会用第一个UNIQUE且NOT NULL的列来作为聚集索引。UNIQUE索引,会内部根据行ID值生成一个隐藏的聚簇索引GEN_CLUST_INDEX。所以在建表的时候,如果没有逻辑唯一且非空列时,可以添加一个auto_increment的列,方便建立一个聚集索引。
非聚集索引又叫辅助索引,叶子节点并不包含行记录数据,而是存储了聚集索引键。
根据示例数据(idx_name索引)构建如图2-2所示辅助索引:
NAME=Jake的数据第一阶段:通过辅助索引查到主键索引的主键
第二阶段:通过主键索引找到完整的行记录
查找结束。
未完待续…
原文链接:MySQL索引(二)B+树在磁盘中的存储 - 掘金 https://juejin.im/post/5cef2c43e51d45572c05ffe3