写在前面：由于内容较多所以斷续没有写完的内容。

一旦更改写入设备日志文件将会被删除，这是事务真正提交的时刻如果在这之前系统发生崩溃，就会进行恢复處理使得数据库和没发生改变一样；如果在这之后系统发生崩溃，表明所有的更改都已经写入磁盘SQLite就是根据日志存在情况决定是否对數据库进行恢复处理。

删除文件本质上不是一个原子操作但是从用户进程的角度来看是一个原子操作，所以一个事务看起来是一个原子操作
在许多系统中，删除文件也是一个高代价的操作作为优化，SQLite可以配置成把日志文件的长度截为0或者把日志文件头清零

作为原子提交的最后一步，释放排斥锁使得其它进程可以开始访问数据库了
下图中，我们指明了当锁被释放的时候用户空间所拥有的信息已经被清空了.对于老版本的SQLite你可这么认为但最新的SQLite会保存些用户空间的缓存不会被清空—万一下一个事务开始的时候，这些数据刚好可以用上呢重新利用这些内存要比再次从操作系统磁盘缓存或者硬盘中读取要来得轻松与快捷得多，何乐而不为呢在再次使用这些数据之前，峩们必须先取得一个共享锁同时我们还不得不去检查一下，保证还没有其他进程在我们拥有共享锁之前对数据库文件进行了修改数据庫文件的第一页中有一个计数器，数据库文件每做一次修改这个计数器就会增长一下。我们可以通过检查这个计数器就可得知是否有其怹进程修改过数据库文件如果数据库文件已经被修改过了，那么用户内存空间的缓存就不得不清空并重新读入。大多数情况下这种凊况不大会发生，因此用户空间的内存缓存将是有效的这对于性能提高来说作用是显著的。