寫在前面:謝謝各位的關注,沒想到會有這么多人關注。高興的同時,也感到壓力,因為我接觸SQLite也就幾天,也沒在實際開發(fā)中用過,只是最近項目的需求才來研究它,所以我很擔心自己的文章是否會有錯誤,誤導別人。但是我很想把自己的學習成果與大家分享,所以如果大家覺得我有不對的地方,望不吝賜教。
我原打算直接從VDBE入手的,因為它起著承上啟下的作用,是整個SQLite的核心,并分析源碼,但考慮到這是一個系列的文章,我希望能把問題說全,所以還是從基本概念入手,對于初學者,如果沒有這些概念,是很繼續(xù)下去的。好了,下面開始第二章,由于這一章內(nèi)容很多,我將分兩部分討論,下面開始第一部分。
1、API
由兩部分組成: 核心API(core API) 和擴展API(extension API)
核心API的函數(shù)實現(xiàn)基本的數(shù)據(jù)庫操作:連接數(shù)據(jù)庫,處理SQL,遍歷結果集。它也包括一些實用函數(shù),比如字符串轉換,操作控制,調(diào)試和錯誤處理。
擴展API通過創(chuàng)建你自定義的SQL函數(shù)去擴展SQLite。
1.1、SQLite Version 3的一些新特點:
(1)SQLite的API全部重新設計,由第二版的15個函數(shù)增加到88個函數(shù)。這些函數(shù)包括支持UTF-8和UTF-16編碼的功能函數(shù)。
(2)改進并發(fā)性能。加鎖子系統(tǒng)引進一種鎖升級模型(lock escalation model),解決了第二版的寫進程餓死的問題(該問題是任何一個DBMS必須面對的問題)。這種模型保證寫進程按照先來先服務的算法得到排斥鎖(Exclusive Lock)。甚至,寫進程通過把結果寫入臨時緩沖區(qū)(Temporary Buffer),可以在得到排斥鎖之前就能開始工作。這對于寫要求較高的應用,性能可提高400%(引自參考文獻)。
(3)改進的B-樹。對于表采用B+樹,大大提高查詢效率。
(4)SQLite 3最重要的改變是它的存儲模型。由第二版只支持文本模型,擴展到支持5種本地數(shù)據(jù)類型。
總之,SQLite Version 3與SQLite Vertion 2有很大的不同,在靈活性,特點和性能方面有很大的改進。
1.2、主要的數(shù)據(jù)結構(The Principal Data Structures)
SQLite由很多部分組成-parser,tokenize,virtual machine等等。但是從程序員的角度,最需要知道的是:connection, statements, B-tree和pager。它們之間的關系如下:
上圖告訴我們在編程需要知道的三個主要方面:API,事務(Transaction)和鎖(Locks)。從技術上來說,B-tree和pager不是API的一部分。但是它們卻在事務和鎖上起著關鍵作用(稍后將討論)。
1.3、Connections和Statements
Connection和statement是執(zhí)行SQL命令涉及的兩個主要數(shù)據(jù)結構,幾乎所有通過API進行的操作都要用到它們。一個連接(Connection)代表在一個獨立的事務環(huán)境下的一個連接A (connection represents a single connection to a database as well as a single transaction context)。每一個statement都和一個connection關聯(lián),它通常表示一個編譯過的SQL語句,在內(nèi)部,它以VDBE字節(jié)碼表示。Statement包括執(zhí)行一個命令所需要一切,包括保存VDBE程序執(zhí)行狀態(tài)所需的資源,指向硬盤記錄的B-樹游標,以及參數(shù)等等。
1.4、B-tree和pager
一個connection可以有多個database對象---一個主要的數(shù)據(jù)庫以及附加的數(shù)據(jù)庫,每一個數(shù)據(jù)庫對象有一個B-tree對象,一個B-tree有一個pager對象(這里的對象不是面向對象的“對象”,只是為了說清楚問題)。
Statement最終都是通過connection的B-tree和pager從數(shù)據(jù)庫讀或者寫數(shù)據(jù),通過B-tree的游標(cursor)遍歷存儲在頁面(page)中的記錄。游標在訪問頁面之前要把數(shù)所從disk加載到內(nèi)存,而這就是pager的任務。任何時候,如果B-tree需要頁面,它都會請求pager從disk讀取數(shù)據(jù),然后把頁面(page)加載到頁面緩沖區(qū)(page cache),之后,B-tree和與之關聯(lián)的游標就可以訪問位于page中的記錄了。
如果cursor改變了page,為了防止事務回滾,pager必須采取特殊的方式保存原來的page。總的來說,pager負責讀寫數(shù)據(jù)庫,管理內(nèi)存緩存和頁面(page),以及管理事務,鎖和崩潰恢復(這些在事務一節(jié)會詳細介紹)。
總之,關于connection和transaction,你必須知道兩件事:
(1)對數(shù)據(jù)庫的任何操作,一個連接存在于一個事務下。
(2)一個連接決不會同時存在多個事務下。
whenever a connection does anything with a database, it always operates under exactly one
transaction, no more, no less.
1.5、核心API
核心API 主要與執(zhí)行SQL命令有關,本質上有兩種方法執(zhí)行SQL語句:prepared query 和wrapped query。Prepared query由三個階段構成:preparation,execution和finalization。其實wrapped query只是對prepared query的三個過程包裝而已,最終也會轉化為prepared query的執(zhí)行。
1.5.1、連接的生命周期(The Connection Lifecycle)
和大多數(shù)據(jù)庫連接相同,由三個過程構成:
?。?)連接數(shù)據(jù)庫(Connect to the database):
每一個SQLite數(shù)據(jù)庫都存儲在單獨的操作系統(tǒng)文件中,連接,打開數(shù)據(jù)庫的C API為:sqlite3_open(),它的實現(xiàn)位于main.c文件中,如下:
int sqlite3_open(const char *zFilename, sqlite3 **ppDb)
{
return openDatabase(zFilename, ppDb, SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE, 0);
}
當連接一個在磁盤上的數(shù)據(jù)庫,如果數(shù)據(jù)庫文件存在,SQLite打開一個文件;如果不存在,SQLite會假定你想創(chuàng)建一個新的數(shù)據(jù)庫。在這種情況下,SQLite不會立即在磁盤上創(chuàng)建一個文件,只有當你向數(shù)據(jù)庫寫入數(shù)據(jù)時才會創(chuàng)建文件,比如:創(chuàng)建表、視圖或者其它數(shù)據(jù)庫對象。如果你打開一個數(shù)據(jù),不做任何事,然后關閉它,SQLite會創(chuàng)建一個文件,只是一個空文件而已。
另外一個不立即創(chuàng)建一個新文件的原因是,一些數(shù)據(jù)庫的參數(shù),比如:編碼,頁面大小等,只在在數(shù)據(jù)庫創(chuàng)建前設置。默認情況下,頁面大小為1024字節(jié),但是你可以選擇512-32768字節(jié)之間為 2冪數(shù)的數(shù)字。有些時候,較大的頁面能更有效的處理大量的數(shù)據(jù)。
(2)執(zhí)行事務(Perform transactions):
all commands are executed within transactions。默認情況下,事務自動提交,也就是每一個SQL語句都在一個獨立的事務下運行。當然也可以通過使用BEGIN..COMMIT手動提交事務。
?。?)斷開連接(Disconnect from the database):
主要是關閉數(shù)據(jù)庫的文件。
1.5.2、執(zhí)行Prepared Query
前面提到,預處理查詢(Prepared Query)是SQLite執(zhí)行所有SQL命令的方式,包括以下三個過程:
(1)Prepared Query:
分析器(parser),分詞器(tokenizer)和代碼生成器(code generator)把SQL Statement編譯成VDBE字節(jié)碼,編譯器會創(chuàng)建一個statement句柄(sqlite3_stmt),它包括字節(jié)碼以及其它執(zhí)行命令和遍歷結果集的所有資源。
相應的C API為sqlite3_prepare(),位于prepare.c文件中,如下:
int sqlite3_prepare(
sqlite3 *db,
const char *zSql,
int nBytes,
sqlite3_stmt **ppStmt,
const char **pzTail
){
int rc;
rc = sqlite3LockAndPrepare(db,zSql,nBytes,0,ppStmt,pzTail);
assert( rc==SQLITE_OK || ppStmt==0 || *ppStmt==0 );
return rc;
}
(2)Execution:
虛擬機執(zhí)行字節(jié)碼,執(zhí)行過程是一個步進(stepwise)的過程,每一步(step)由sqlite3_step()啟動,并由VDBE執(zhí)行一段字節(jié)碼。由sqlite3_prepare編譯字節(jié)代碼,并由sqlite3_step()啟動虛擬機執(zhí)行。在遍歷結果集的過程中,它返回SQLITE_ROW,當?shù)竭_結果末尾時,返回SQLITE_DONE。
(3)Finalization:
VDBE關閉statement,釋放資源。相應的C API為sqlite3_finalize()。
通過下圖可以更容易理解該過程:
最后以一個具體的例子結束本節(jié),下節(jié)討論事務。
#include
#include
#include"sqlite3.h"
#include
intmain(intargc,char**argv)
{
int rc,i,ncols;
sqlite3 *db;
sqlite3_stmt *stmt;
char *sql;
const char*tail;
//打開數(shù)據(jù)
rc=sqlite3_open("foods.db",&db);
if(rc){
fprintf(stderr,"Can'topendatabase:%sn",sqlite3_errmsg(db));
sqlite3_close(db);
exit(1);
}
sql="select * from episodes";
//預處理
rc=sqlite3_prepare(db,sql,(int)strlen(sql),&stmt,&tail);
if(rc!=SQLITE_OK){
fprintf(stderr,"SQLerror:%sn",sqlite3_errmsg(db));
}
rc=sqlite3_step(stmt);
ncols=sqlite3_column_count(stmt);
while(rc==SQLITE_ROW){
for(i=0;i fprintf(stderr,"'%s'",sqlite3_column_text(stmt,i));
}
fprintf(stderr,"n");
rc=sqlite3_step(stmt);
}
//釋放statement
sqlite3_finalize(stmt);
//關閉數(shù)據(jù)庫
sqlite3_close(db);
return0;
}