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锁