接下来基于这棵B树，我们举个例子，来查找17这个数字：
第一步：内存加载根节点13，我们比较发现17>13，找13的右侧分叉节点（15，20）
第二步：内存加载节点（15，20），我们比较15，发现 17>15,再比较20，发现17<20,于是取出15的右侧分叉节点（16，17）
第三步：内存加载节点（16，17），我们比较16，发现17>16,再比较17，发现17=17，发现命中，取出17所对应的数据。
我们再举个例子，来查找18这个数字：
前两步都相同
第三步：内存加载节点（16，17），我们比较16，发现18>16,再比较17，发现18>17，于是我们要找17右侧的分叉，但是此时右侧的叶子节点为空（17的右侧分叉对应叶子节点，叶子节点为空），所以我们断定，18不存在。
注意无论是否存在，我们最多都只用了3次内存加载，就完成了比较查找。
这里要特别提下，为啥我们只看重内存加载的速度，而忽略比较次数的耗时呢？这是因为我们在分析性能问题时，需要着重性能的瓶颈来分析。磁盘的读取和内存的访问接近有5个数量级的差异（单位大概是10毫秒与50微秒的差距）。因此我们在这里比较性能时，就是要看进行了多少次磁盘的读取（磁盘的IO），并且主要以减少磁盘IO的手段来提升性能。
当然为了提升比较次数，我们还可以采用二分查找的方式，来判断节点中是否包含某个关键字，进一步加快速度。
接下来影响提升整个IO次数的瓶颈就出现在，一个节点到底能存储多少个关键字，如果关键字存储的越多，我们一次加载到内存中的数据也就越多。同时也要注意，这个关键字的个数不能设置成无限大，因为内存不足以支撑一次加载太多的数据。
基于以上种种，我们可以发现，B树是基于传统硬盘与内存之间的IO差距，而专门设计出来的数据结构，他天然就适用于文件系统。
而对于B树的升级版B+树（B plus tree）,我会在接下来的文章中专门讲讲,它又有什么不一样的地方。