区分Sqlite中的B-树和B+树——索引和存储

在网上看一些帖子的时候。发现有人说Sqlite中组织管理数据库文件存储的机制为B-树。

本人觉着这么说非常的不严谨。

于是本人翻出了《the definitive guide to sqlite》SECOND EDITON。经过再次查阅，想在这里总结一下。

在Sqlite中B-树和B+树的出处的却别，换句话说。就是SQLite这个嵌入式数据库中，索引机制和文件存储机制的区别。

1.索引

对索引多说几句吧，我们去砍树，可以用手把它推到，但是利用斧子可以很快的把树干倒。

检索操作（更新，删除，插入都会用到检索操作）就如砍树，索引就是我们的斧子。

首先他和好用。加快了检索速度。同时如斧子一样。不是让你白用的。斧子是买来的。就是借来的也是欠了个人情的。总之就是

使用索引（斧子）去检索数据（去看书）是需要代价的。

没错，这是必须的。斧子放在家里占地方啊。索引也是占内存的啊。亲，而且如果不是内存数据库，索引还要占外存的地方呢。

斧子花钱了。除了检索操作不需要更新索引，删除，插入都要更新索引啊，亲，这就是辅助性工具的开销。

我们一定要明确一点。索引和表、数组、一个变量一样是实实在在的在我们的硬盘上或者内存中躺着的。

说的再直白一些，他就是个数据结构（其实数据结构这个词听抽象的，你觉得呢？）。总之就是，占内存，我们用程序可以直接控制他的。

他可以清清楚楚的躺在我们的面前。不要嫌我啰嗦，这些就是索引的本质。

上面说到，索引和数据结构很近。好吧。我们比较典型的索引数据结构有两大类，1：散列，其通过一个叫散列函数的东西，利用数值计算，便可很快得知

目标记录所在散列表位置，然后根据散列表位置里的信息便可快速找到它了。又分静态散列和动态散列，关于他们的知识点，百度吧，谷歌吧。

2：树，随着数据量的增长，树能自己调整自己。可以容纳很多数据。利用对比来快速定位，往往对比次数与树的深度有很大关系。一般成

对数级的时间复杂度。一般典型的有B数（又名B-树，不要说有那么一个树叫B减树或者B杠树），B+树，AVL树，红黑树（RBTree）。

关于他们的知识点，百度吧，谷歌吧。。

2.存储

我说的简单些吧。

内存小，外存大。数据库文件大，内存装不下，怎么办？解决方法很简单。先装一部分，先使吧。

很眼熟啊感觉。

操作系统里有木有？（动态或静态）页面管理机制有木有？缺页中断有木有？

这里有个概念“页面（pager）”。sqlite中是这么说的。一个数据库文件被连续的分割成了X个页面，并给个页面号。就是“块儿”和“块儿号”。

这点东西不熟悉的再查查相关资料吧。

3.SQLite中B树和B+树的应用。

上图是从文章开头处的书中，解出来的一段。

他说了。所有数据库中的页面都是从1开始顺序编号的。一个数据库中可以有多个B树----每个表或者索引都对应着一个B树（B+树用于表，B树用于索引）。

在数据库中每一个表或者索引都有一个用于定义其首页面位置的根页面（这样就有了很多歌根页面）。所有索引和表的根页面都存储在SQLITE_master表中。

我们得到两点：

1：B+树用于表，B树用于索引

2：在本书中，没有刻意区分B+树和B树，把他们通称为B树。

B-树节点（页面）包括关键词域和数据域。红线部分可以看出：数据域就是数据库记录的变形。

蓝色线可以印证本书中确实将两者统称为B树了。

图片前的那句红线说，组织表用的B+树中的内部页面并不包含数据记录。图片后的红线说，B+树的数据域都指向下级页面。数据库记录都存储在叶子页面。

总之，这本书中，对B树和B+树统称为B树，没有加以细分。但是我们这些读者要搞清楚，什么时候是B树，什么时候是B+树。关于他们的理论知识和SQLite中的相关东西请参考其他资料。

由于跟记录有关的信息存放在叶结点中，查找时若在上层已找到待查的关键码，并不停止，而是继续沿指针向下一直查到叶结点层的关键码。此外，B+树的所有叶结点构成一个有序链表，可以按照关键码排序的次序遍历全部记录。上面两种方式结合起来，使得B+树非常适合范围检索。

B树的好处，就是成功查询特别有利，因为树的高度总体要比B+树矮。不成功的情况下，B树也比B+树稍稍占一点点便宜。

有很多基于频率的搜索是选用B树，越频繁query的结点越往根上走，前提是需要对query做统计，而且要对key做一些变化。

内存中B+树是没有优势的，但是一到磁盘，B+树的威力就出来了"。