WAL（write-ahead log，预写式日志）文件格式(2)

读算法

从数据库中读一页（假设为页P），读者首先检查WAL来确定是否包含页P，如果包含，那么页P的最后一个有效实例是在该 WAL框中。如果WAl没有包含页P，那么页P就从数据库文件中读入。

开始一个读事务时，读者记录WAL中最后一个有效的框的索引。读者用myFrame值记录所有的子顺序读操作。新的事务能被添加到WAl中，只要读者使用原始的myFrame值并且忽略新的增加的内容，它将看到一个快照。这个技术允许多事务并行读不同的数据库内容。

这个读算法可以正确工作，但是因为对于页P的框可能出现在WAl的任何地方，读者必须读WAL中所有的条目来寻找页P对应的框。如果WAL比较大（通常是几兆）遍历可能比较慢，读性能会比较糟糕。为了克服这个问题，一个称为wal-index数据结构来加速搜索特定页的框。

WAL-INDEX 格式

从概念上来说，wal-index应该在共享内存里面，尽管VFS实现可能选择使用一个内存映射文件来实现。因为这个wal-index是共享内存里，SQLite在一个网络文件系统里面不支持WAL机制。数据库的所有使用者都必须可以使用共享内存。

Wal-index不是长久存储的。系统崩溃以后，wal-index可用从原始的WAL文件中重新构建。事实上，当最后一个连接关闭之后，系统就会调用VFS来处理wal-index的头结点，或者将其截断或者将其置零。因为wal-index是临时性的，所以它可以使用特定的系统格式；它不需要跨平台。因此，不想数据库和WAL文件格式以大端模式存储所有的值，wal-index在用户机上以自然顺序存储多键值。

Wal-index的目的是为了更快速的回答这个问题：给一个页号P，返回P在WAL日志中最后一个框的索引，如果P不准WAL中，则返回NULL。

Wal-index包含一个头区域，跟着一些索引块。

Wal-index头区域包含wal文件中所有框的数目。

除了第一个包含信息以外的每个索引块都在HASHTABLE_NPAGE框中。第一个索引块在HASHTABLE_NPAGE_ONE框中。HASHTABLE_NPAGE_ONE和HASHTABLE_NPAGE都可以被选择，所有wal-index头和第一个块跟其他的索引块是一样大的。

每一个索引块包括两部分，一个页映射，它存储数据库页号和每个wal框的联系；一个哈希表，运行读者根据一个特定的页号查询索引块。页映射是一系列的HASHTABLE_NPAGE 32位的页号。第一个索引块的第一个条目保存着数据库总页数映射第一个框。最后一个索引块经常保存比慢的HSHTABLE_NPAGE少的页数目，根据WAL文件大小。这不会改变的页面映射数组分配大小 - 页映射数组只包含未使用的条目。

页面P的最后一帧，即使没有使用哈希表，可以发现扫描最后一个索引块中的每个索引的起始块的页映射部分和移动向第一，并在每个索引块，在年底开始开始走向。等于P的第一项对应的框架页的内容。

哈希表包含HASHTABLE_NSLOT 16位无符号整数。HASHTABLE_NSLOT=2*HASHTABLE_NPAGE，每个映射部分的页码有一个哈希表中的条目，所以哈希表是从来没有超过一半。