在網上看一些帖子的時候。發現有人說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+樹的威力就出來了"。