SQLite中的隔离(八）

返回：SQLite—系列文章目录

上一篇：SQLite版本3中的文件锁定和并发(七）

下一篇：SQLite 查询优化器概述（九）

数据库的“isolation”属性确定何时对一个操作的数据库对其他并发操作可见。

数据库连接之间的隔离

如果使用两个不同的数据库连接读取和写入同一个数据库（两个不同的 sqlite3 对象返回单独调用 sqlite3_open（））和两个数据库连接没有共享缓存，则读取器只能请参阅编写器的完整已提交事务。部分更改作者没有承诺的对读者来说是不可见的。无论两个数据库连接是否在同一线程，在同一进程的不同线程中，或在不同的过程。这是 SQL 数据库系统的常见行为和预期行为。

上一段也是正确的（单独的数据库连接是彼此隔离）在共享缓存模式下，只要read_uncommitted编译指示保持关闭状态即可。默认情况下，read_uncommitted编译指示处于关闭状态，因此，如果应用程序不执行任何操作来打开它，它将保持关闭状态。因此，除非使用read_uncommitted编译指示若要更改默认行为，请由一个数据库连接所做的更改对于共享相同的缓存，直到写入器提交其事务。

如果两个数据库连接共享同一个缓存，并且读取器具有启用了read_uncommitted编译指示，然后读者将能够请参阅编写器在编写器事务提交之前所做的更改。共享缓存模式和read_uncommitted指示的组合使用是一个数据库连接可以查看未提交的更改的唯一方法在不同的数据库连接上。在所有其他情况下，分开数据库连接彼此完全隔离。

除了打开PRAGMA read_uncommitted共享缓存数据库连接的情况外，SQLite中的所有事务都显示 “可序列化”隔离。SQLite 实现可序列化事务通过实际序列化写入。只能有一个作家一次到一个 SQLite 数据库。可以有多个数据库连接同时打开，所有这些数据库连接都可以写入到数据库文件，但他们必须轮流。SQLite使用锁自动序列化写入;这不是什么使用SQLite的应用程序需要担心。

隔离和并发

SQLite 使用与数据库文件位于同一目录中的暂时性日志文件。有两种主要的“日志模式”。较旧的“回滚模式”对应于使用“DELETE”、“PERSIST”、或“TRUNCATE”选项添加到journal_mode编译指示中。在回滚模式下，更改将直接写入数据库文件，同时构造一个单独的回滚日志文件，该文件能够恢复如果事务回滚，则数据库恢复到其原始状态。回滚模式（特别是 DELETE 模式，即回滚日志在每次事务结束时从磁盘中删除）是当前默认行为。

从3.7.0版（2010-07-21）开始， SQLite还支持“WAL模式”。在 WAL 模式下，更改不会写入原始数据库文件。相反，更改进入单独的“预写日志”或“WAL”文件。后来，交易后提交时，这些更改将从 WAL 文件移回原始数据库在名为“checkpoint”的操作中。WAL 模式是通过运行“PRAGMA journal_mode=WAL”启用。

在回滚模式下，SQLite通过锁定数据库来实现隔离文件并防止其他数据库连接读取而每个写入事务都在进行中。读者可以在写作开始时，在任何内容之前处于活动状态刷新到磁盘，而所有更改仍保存在编写器的专用内存空间。但在对数据库文件进行任何更改之前在磁盘上，必须（暂时）驱逐所有读取器才能给写入器对数据库文件的独占访问。因此，禁止读者看到不完整的内容由于被锁定在数据库之外的事务，而事务正在写入磁盘。只有在交易之后完全写入并同步到磁盘并提交是允许的读取器返回到数据库中。因此，读者永远没有机会看到部分内容书面更改。

WAL 模式允许同时读取和写入。它可以这样做，因为更改不会覆盖原始数据库文件，而是执行添加到单独的预写日志文件中。这意味着读者可以继续从原始数据库文件中读取旧的、原始的、未更改的内容同时，编写器将追加到预写日志中。在WAL模式下，SQLite表现出“快照隔离”。当读取事务时开始，该读者继续看到数据库的不变“快照” 文件，因为它在读取事务开始时存在。在读取事务 active 对读取事务仍然不可见，因为读取器是查看前一时刻的数据库文件快照。

举个例子：假设有两个数据库连接 X 和 Y。使用 BEGIN 后跟一个或多个 SELECT 语句的读取事务。然后 Y 出现并运行 UPDATE 语句来修改数据库。 X 随后可以对 Y 修改的记录执行 SELECT，但 X 将看到较旧的未修改条目，因为 Y 的更改都是当 X 持有读取事务时，X 不可见。如果 X 想看 Y 所做的更改，则 X 必须结束其读取事务，并且启动一个新的（通过运行 COMMIT，然后运行另一个 BEGIN）。

另一个示例：X 使用 BEGIN 和 SELECT 启动读取事务，然后 Y 使用 UPDATE 对数据库进行更改。然后 X 尝试做一个使用 UPDATE 更改为数据库。X 试图升级其从读取事务到写入事务的事务失败并显示SQLITE_BUSY_SNAPSHOT错误，因为数据库的快照正在查看的 X 不再是数据库的最新版本。如果 X 是允许写入，它将分叉数据库文件的历史记录，即 SQLite不支持的东西。为了让 X 写入数据库，它必须首先发布其快照（例如使用 ROLLBACK），然后使用后续 BEGIN 启动新事务。

如果 X 启动一个事务，该事务最初只会读取但 X 知道它最终会想写，不想被烦恼由于另一个连接而可能出现的SQLITE_BUSY_SNAPSHOT错误在队列中跳到它前面，然后 X 可以发出 BEGIN IMMEDIATELY 来启动它的交易而不仅仅是普通的 BEGIN。BEGIN IMMEDIATE 命令继续并启动写入事务，从而阻止所有其他作家。如果 BEGIN IMMEDIATE 操作成功，则没有该事务中的后续操作将失败并出现SQLITE_BUSY错误。

同一数据库连接上的操作之间没有隔离

SQLite 在单独的数据库中提供操作之间的隔离连接。但是，操作之间没有隔离发生在同一数据库连接中。

换言之，如果 X 使用 BEGIN IMMEDIATE 开始写入事务，然后发出一个或多个 UPDATE、DELETE 和/或 INSERT 语句，则这些更改对后续 SELECT 语句可见在数据库连接 X 中计算的。不同的数据库连接 Y 将不显示任何更改，直到 X 事务提交。但是 X 中的 SELECT 语句将显示更改在提交之前。

在单个数据库连接 X 中，SELECT 语句始终看到所有在 SELECT 开始之前完成的对数据库的更改语句，无论是已提交的还是未提交的。和 SELECT 语句显然看不到 SELECT 语句之后发生的任何更改完成。但是，在 SELECT 语句中发生的更改呢？正在跑步吗？如果启动了 SELECT 语句，并且 sqlite3_step（）接口单步执行了大约一半的输出，则某些 UPDATE 语句由修改表的应用程序运行，该 SELECT 语句正在读取，然后对 sqlite3_step（）进行更多调用完成 SELECT 语句？将 SELECT 的后续步骤声明是否看到 UPDATE 所做的更改？答案是此行为未定义。特别是，无论 SELECT 语句是否看到并发更改取决于 SQLite 的哪个版本 running，数据库文件的架构，无论 ANALYZE 是否具有已运行，以及查询的详细信息。在某些情况下，这可能取决于在数据库文件的内容上也是如此。没有好的方法可以知道是否或者 SELECT 语句不会看到对数据库所做的更改通过启动 SELECT 语句后的同一数据库连接。因此，开发人员应该努力避免编写应用程序对在这种情况下会发生什么做出假设。

如果应用程序在单个表上发出 SELECT 语句，例如 “SELECT rowid， * FROM table WHERE ...” 并开始单步执行使用 sqlite3_step（）的该语句的输出并检查每个行，则应用程序可以安全地删除当前行或使用“DELETE FROM table WHERE rowid=？”的任何前行。它也是安全的（从某种意义上说，它不会损害数据库）让应用程序删除预计稍后在查询中出现但尚未出现的行出现了。但是，如果删除了将来的行，则可能会发生以下情况该行在随后的 sqlite3_step（）之后出现，即使在它有据称已被删除。或者它可能不是。该行为是未定义的。应用程序可以此外，当 SELECT 语句正在运行，但是否显示新行在查询的后续 sqlite3_step（）中未定义。和应用程序可以更新当前行或任何前一行，但这样做可能会导致该行将在随后的 sqlite3_step（）中重新出现。只要应用程序准备处理这些歧义，操作它们本身是安全的，不会损害数据库文件。

就前两段而言，两个数据库连接具有相同共享缓存且已启用 PRAGMA read_uncommitted的数据库连接被视为相同的数据库连接。