一、什么是WAL？

WAL的全稱是Write Ahead Logging，它是很多數(shù)據(jù)庫中用于實現(xiàn)原子事務的一種機制，SQLite在3.7.0版本引入了該特性。

二、WAL如何工作？

在引入WAL機制之前，SQLite使用rollback journal機制實現(xiàn)原子事務。

rollback journal機制的原理是：在修改數(shù)據(jù)庫文件中的數(shù)據(jù)之前，先將修改所在分頁中的數(shù)據(jù)備份在另外一個地方，然后才將修改寫入到數(shù)據(jù)庫文件中；如果事務失敗，則將備份數(shù)據(jù)拷貝回來，撤銷修改；如果事務成功，則刪除備份數(shù)據(jù)，提交修改。

WAL機制的原理是：修改并不直接寫入到數(shù)據(jù)庫文件中，而是寫入到另外一個稱為WAL的文件中；如果事務失敗，WAL中的記錄會被忽略，撤銷修改；如果事務成功，它將在隨后的某個時間被寫回到數(shù)據(jù)庫文件中，提交修改。

同步WAL文件和數(shù)據(jù)庫文件的行為被稱為checkpoint（檢查點），它由SQLite自動執(zhí)行，默認是在WAL文件積累到1000頁修改的時候；當然，在適當?shù)臅r候，也可以手動執(zhí)行checkpoint，SQLite提供了相關的接口。執(zhí)行checkpoint之后，WAL文件會被清空。

在讀的時候，SQLite將在WAL文件中搜索，找到最后一個寫入點，記住它，并忽略在此之后的寫入點（這保證了讀寫和讀讀可以并行執(zhí)行）；隨后，它確定所要讀的數(shù)據(jù)所在頁是否在WAL文件中，如果在，則讀WAL文件中的數(shù)據(jù)，如果不在，則直接讀數(shù)據(jù)庫文件中的數(shù)據(jù)。

在寫的時候，SQLite將之寫入到WAL文件中即可，但是必須保證獨占寫入，因此寫寫之間不能并行執(zhí)行。

WAL在實現(xiàn)的過程中，使用了共享內(nèi)存技術，因此，所有的讀寫進程必須在同一個機器上，否則，無法保證數(shù)據(jù)一致性。

三、WAL的優(yōu)點與缺點

優(yōu)點：

1.讀和寫可以完全地并發(fā)執(zhí)行，不會互相阻塞（但是寫之間仍然不能并發(fā)）。
2.WAL在大多數(shù)情況下，擁有更好的性能（因為無需每次寫入時都要寫兩個文件）。
3.磁盤I/O行為更容易被預測。

缺點：

1.訪問數(shù)據(jù)庫的所有程序必須在同一主機上，且支持共享內(nèi)存技術。
2.每個數(shù)據(jù)庫現(xiàn)在對應3個文件：<yourdb>.db，<yourdb>-wal，<yourdb>-shm。
3.當寫入數(shù)據(jù)達到GB級的時候，數(shù)據(jù)庫性能將下降。
4.3.7.0之前的SQLite無法識別啟用了WAL機制的數(shù)據(jù)庫文件。

四、WAL引入的兼容性問題

在啟用了WAL之后，數(shù)據(jù)庫文件格式的版本號由1升級到了2，因此，3.7.0之前的SQLite無法識別啟用了WAL機制的數(shù)據(jù)庫文件。

禁用WAL會使數(shù)據(jù)庫文件格式的版本號恢復到1，從而可以被SQLite 3.7.0之前的版本識別。

五、WAL引入的性能問題

在一般情況下，WAL會提高SQLite的事務性能；但是在某些極端情況下，卻會導致SQLite事務性能的下降。

1.在事務執(zhí)行時間較長或者要修改的數(shù)據(jù)量達到GB級的時候，WAL文件會被占用，它會暫時阻止checkpoint的執(zhí)行（checkpoint會清空WAL文件），這將導致WAL文件變得很大，增加尋址時間，最終導致讀寫性能的下降。
2.當checkpoint執(zhí)行的時候，會降低當時的讀寫性能，因此，WAL可能會導致周期性的性能下降。

六、與WAL相關的PRAGMA和接口