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的数据库连接被视为相同的数据库连接。

总结

1. SQLite 中的事务是可序列化的。

2. 在一个数据库连接中所做的更改对所有其他数据库都是不可见的 提交前的连接。

3. 查询将查看在同一数据库连接上完成的所有更改 在查询开始之前，无论这些更改是否发生 已经提交。

4. 如果查询后同一数据库连接发生更改 开始运行，但在查询完成之前，则不确定是否 或者查询不会看到这些更改。

5. 如果查询后同一数据库连接发生更改 开始运行，但在查询完成之前，查询可能会返回 多次更改的行，或者它可能会返回以前更改的行 删除。

6. 就前四项而言，两个数据库连接 使用相同的共享缓存，并且启用 PRAGMA read_uncommitted 被视为相同的数据库连接，而不是单独的数据库 连接。