4.索引的数据结构
前面讲了生活中索引的例子 ， 索引的基本原理 ， 数据库的复杂性 ， 又讲了操作系统的相关知识 ， 目的就是让大家了解 ， 任何一种数据结构都不是凭空产生的 ， 一定会有它的背景和使用场景 ， 我们现在总结一下 ， 我们需要这种数据结构能够做些什么 ， 其实很简单 ， 那就是：每次查找数据时把磁盘IO次数控制在一个很小的数量级 ， 最好是常数数量级 。那么我们就想到如果一个高度可控的多路搜索树是否能满足需求呢？就这样 ， b+树应运而生 。
5.详解b+树
文章插图
如上图 ， 是一颗b+树 ， 关于b+树的定义可以参见B+树 ， 这里只说一些重点 ， 浅蓝色的块我们称之为一个磁盘块 ， 可以看到每个磁盘块包含几个数据项（深蓝色所示）和指针（黄色所示） ， 如磁盘块1包含数据项17和35 ， 包含指针P1、P2、P3 ， P1表示小于17的磁盘块 ， P2表示在17和35之间的磁盘块 ， P3表示大于35的磁盘块 。真实的数据存在于叶子节点即3、5、9、10、13、15、28、29、36、60、75、79、90、99 。非叶子节点只不存储真实的数据 ， 只存储指引搜索方向的数据项 ， 如17、35并不真实存在于数据表中 。
6.b+树的查找过程
如图所示 ， 如果要查找数据项29 ， 那么首先会把磁盘块1由磁盘加载到内存 ， 此时发生一次IO ， 在内存中用二分查找确定29在17和35之间 ， 锁定磁盘块1的P2指针 ， 内存时间因为非常短（相比磁盘的IO）可以忽略不计 ， 通过磁盘块1的P2指针的磁盘地址把磁盘块3由磁盘加载到内存 ， 发生第二次IO ， 29在26和30之间 ， 锁定磁盘块3的P2指针 ， 通过指针加载磁盘块8到内存 ， 发生第三次IO ， 同时内存中做二分查找找到29 ， 结束查询 ， 总计三次IO 。真实的情况是 ， 3层的b+树可以表示上百万的数据 ， 如果上百万的数据查找只需要三次IO ， 性能提高将是巨大的 ， 如果没有索引 ， 每个数据项都要发生一次IO ， 那么总共需要百万次的IO ， 显然成本非常非常高 。
7.b+树性质
1.通过上面的分析 ， 我们知道IO次数取决于b+数的高度h ， 假设当前数据表的数据为N ， 每个磁盘块的数据项的数量是m ， 则有h=㏒(m+1)N ， 当数据量N一定的情况下 ， m越大 ， h越小；而m = 磁盘块的大小 / 数据项的大小 ， 磁盘块的大小也就是一个数据页的大小 ， 是固定的 ， 如果数据项占的空间越小 ， 数据项的数量越多 ， 树的高度越低 。这就是为什么每个数据项 ， 即索引字段要尽量的小 ， 比如int占4字节 ， 要比bigint8字节少一半 。这也是为什么b+树要求把真实的数据放到叶子节点而不是内层节点 ， 一旦放到内层节点 ， 磁盘块的数据项会大幅度下降 ， 导致树增高 。当数据项等于1时将会退化成线性表 。
2.当b+树的数据项是复合的数据结构 ， 比如(name,age,sex)的时候 ， b+数是按照从左到右的顺序来建立搜索树的 ， 比如当(张三,20,F)这样的数据来检索的时候 ， b+树会优先比较name来确定下一步的所搜方向 ， 如果name相同再依次比较age和sex ， 最后得到检索的数据；但当(20,F)这样的没有name的数据来的时候 ， b+树就不知道下一步该查哪个节点 ， 因为建立搜索树的时候name就是第一个比较因子 ， 必须要先根据name来搜索才能知道下一步去哪里查询 。比如当(张三,F)这样的数据来检索时 ， b+树可以用name来指定搜索方向 ， 但下一个字段age的缺失 ， 所以只能把名字等于张三的数据都找到 ， 然后再匹配性别是F的数据了 ， 这个是非常重要的性质 ， 即索引的最左匹配特性 。
慢查询优化
关于MySQL索引原理是比较枯燥的东西 ， 大家只需要有一个感性的认识 ， 并不需要理解得非常透彻和深入 。我们回头来看看一开始我们说的慢查询 ， 了解完索引原理之后 ， 大家是不是有什么想法呢？先总结一下索引的几大基本原则
推荐阅读
- 解密电商系统架构发展历程
- 前阿里ET实验室硬件负责人加盟易控智驾，看矿区自动驾驶如何掘金
- Hbase架构详解
- 带你深入了解高并发架构
- 网站架构模式
- Java反射机制是开发第三方架构的基础
- 微信小程序架构原理
- Apache Beam 架构原理及应用实践
- 微服务架构如何实现网站服务垂直化拆分
- 详细讲解Tomcat系统架构