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