提交前缓存溢出-线性代数及其应用中文版下载

6.3 提交前缓存溢出 节 3.0 描述的提交过程都假定了所有变更的数据都保存在用户内存中，直到真正提交。这是通常会出现的状况。但 有时一个非常大或（多）的修改会超出用户空间的内存缓存大小。在这种情况下，一个事务完成之前，缓存不得不 将数据先写入到数据库中。 在一个缓存发生溢出之前，这个数据库联接的状态如 3.6 节。数据库原始的内容已经被写入回滚日志文件中了，页 面修改部分还保存在用户内存中。要处理这种缓存溢出，SQLite 会执行 3.7 节到 3.9 节。换而言之，回滚日志被 flush 到硬盘，独享锁已经申请到，修改已经被写入到数据库了。但剩余的步骤会延迟，直到这个事务被真正提交。一个 新的日志文件头会追加到回滚日志文件尾部（处于它自己单独的扇区中），独享锁仍然保留，但其他处理则回到节 3.6.当这个事务提交时，或者另外的缓存溢出发生，节 3.7 及节 3.9 会再次发生（节 3.8 在第二次或以后过程中被省 略掉，因为独享锁已经拿到了）。 一次缓存溢会使数据库的临界锁提升到独享锁。这将减少并发。一次缓存溢出也将导致额外的硬盘 flush(fsync)操作， 并将导致这些操作变慢，因此缓存溢出将严重降低性能。由于这些因素，缓存溢出现象应该尽量避免。 7.0 优化 在大部分的操作系统，大多数的工作环境下面，性能指标指示 SQLite 主要费时在磁盘操作上面。如果我们能够减 少磁盘 IO 数量就会显著的提高 SQLite 的性能。本节将描述 SQLite 在不影响提交原子性的前提下，为减少磁盘 IO