Journal模式

SQLite3中的事務

SQLite3中可以使用BEGIN TRANSACTION和COMMIT TRANSACTION來開始和停止一個事務.如果你沒有添加這些事務語句,SQLite3會為你的每條SQL語句加上一個事務.

一次正常執行的事務過程

要想優化SQLite3的性能,那么必需要了解SQLite3中一次事務執行過程.這里已一個有寫操作的并成功執行的事務來舉例.

• 一次文件創立(回滾日志)

• 兩次文件寫入

• 兩次文件沖入(回滾日志,數據庫文件)

• 一次文件刪除(回滾日志)

• 加了3次鎖,最后一次不允許讀取

初始狀態

數據庫打開后,未進行任何數據庫操作時年夜概是下圖的狀態.

這里分了三個部分,左面是用戶空間,中間是內核緩存區(文件的讀寫緩存),右邊是物理磁盤設備(iOS的閃存).在SQLite中數據最小的讀寫單位扇區(sector),通常是512B,圖中每個小矩形代表一個扇區.藍色代表未變動的原始數據,中間白色表示是空的,即此時數據沒有讀取到內核緩存區.

準備讀取(加讀鎖)

任何寫操作都會先進行讀操作,因為寫之前要讀取數據庫的schema,插入和修改的地位等.在讀取操作之間要加上讀鎖.加讀鎖是為了防止其它數據庫連接進行寫操作,而保證讀取時數據不被破壞.這時其它數據庫的讀取操作依然可以正常執行.

讀取數據

加了讀鎖之后就開端讀取數據了：

這里讀取了3個扇區的數據,讀取時通過系統文件讀取挪用,會從內核緩存中拷貝到用戶空間.

準備改動數據(加寫鎖)

數據讀取完畢后,就準備開始改動數據了,改動數據之前首先要加寫鎖,此寫鎖可以和其它進程的讀鎖同時存在：

樹立回滾日志

開始寫操作之前,先建立一個回滾日志文件,已便進行回滾操作.將更改之前的舊數據保存到回滾日志文件中.回滾日志文件包括一個頭信息(綠色部分),記錄回滾必要信息.

在用戶空間中改動數據

圖中粉色表現已修改的數據.

沖(fsync)回滾日志文件

用戶空間修改數據后,未確保回滾日志文件可靠,必須把回滾日志文件沖入物理磁盤進行持久存儲.這樣以確保內核瓦解或斷電后依然可恢復數據.

加互斥鎖

準備開端真正的寫文件了,要加互斥鎖了.互斥鎖可以和已經打開的讀鎖同時存在,但不允許新建讀鎖了.

寫數據庫文件

現在可以平安的寫數據文件了.

沖數據庫文件到持久存儲設備.

刪除回滾日志

沖入數據庫文件后才能刪除回滾日志,確保內核瓦解或斷電后依然可恢復數據.

開釋鎖

非常回滾過程

沖(fsync)數據庫文件

條件檢測

回滾必要滿足以下所有條件

• 存在journal文件

• journal文件內容不為空

• 數據庫沒有reserved鎖

• journal文件格局正確,未被歸零

• journal文件未指定master journal(若已指定,master journal必需也存在)

加互斥鎖

文件回滾

刪除回滾日志

沖入數據庫文件后才能刪除回滾日志,確保內核瓦解或斷電后依然可恢復數據.

開釋互斥鎖至Share鎖