WAL簡介
在數據庫讀寫操作中，經常會有人問到數據庫讀寫同步的問題，即在數據庫操作中，數據正處於寫狀態，此時要讀取的數據爲空狀態，問怎麼操作。其實，說到這就不得不提到數據庫的一個重要的機制WAL，不管是後端的PostSql還是前端的SqlLite，都會涉及到WAL機制。
WAL的全稱是Write Ahead Logging，它是很多數據庫中用於實現原子事務的一種機制，SQLite在3.7.0版本引入了該特性。具體使用時，當事務對數據庫進行修改時，將修改後的頁面存入WAL文件中，而不寫回原數據庫。WAL文件從數據庫的第一個連接建立時創建，在最後一個連接釋放時刪除。
WAL工作原理
在引入WAL機制之前，SQLite使用rollback journal機制實現原子事務。
rollback journal機制的原理是：在修改數據庫文件中的數據之前，先將修改所在分頁中的數據備份在另外一個地方，然後纔將修改寫入到數據庫文件中；如果事務失敗，則將備份數據拷貝回來，撤銷修改；如果事務成功，則刪除備份數據，提交修改。
WAL機制的原理是：修改並不直接寫入到數據庫文件中，而是寫入到另外一個稱爲WAL的文件中；如果事務失敗，WAL中的記錄會被忽略，撤銷修改；如果事務成功，它將在隨後的某個時間被寫回到數據庫文件中，提交修改。
同步WAL文件和數據庫文件的行爲被稱爲checkpoint（檢查點），它由SQLite自動執行，默認是在WAL文件積累到1000頁修改的時候；當然，在適當的時候，也可以手動執行checkpoint，SQLite提供了相關的接口。執行checkpoint之後，WAL文件會被清空。
在讀的時候，SQLite將在WAL文件中搜索，找到最後一個寫入點，記住它，並忽略在此之後的寫入點（這保證了讀寫和讀讀可以並行執行）；隨後，它確定所要讀的數據所在頁是否在WAL文件中，如果在，則讀WAL文件中的數據，如果不在，則直接讀數據庫文件中的數據。
在寫的時候，SQLite將之寫入到WAL文件中即可，但是必須保證獨佔寫入，因此寫寫之間不能並行執行。WAL在實現的過程中，使用了共享內存技術，因此，所有的讀寫進程必須在同一個機器上，否則，無法保證數據一致性。
WAL的優點與缺點
優點：
1.讀和寫可以完全地併發執行，不會互相阻塞（但是寫之間仍然不能併發）。
2.WAL在大多數情況下，擁有更好的性能（因爲無需每次寫入時都要寫兩個文件）。
3.磁盤I/O行爲更容易被預測。
缺點：
1.訪問數據庫的所有程序必須在同一主機上，且支持共享內存技術。
2.每個數據庫現在對應3個文件：<yourdb>.db，<yourdb>-wal，<yourdb>-shm。
3.當寫入數據達到GB級的時候，數據庫性能將下降。
4.3.7.0之前的SQLite無法識別啓用了WAL機制的數據庫文件。
WAL兼容性問題
在啓用了WAL之後，數據庫文件格式的版本號由1升級到了2，因此，3.7.0之前的SQLite無法識別啓用了WAL機制的數據庫文件。禁用WAL會使數據庫文件格式的版本號恢復到1，從而可以被SQLite 3.7.0之前的版本識別。
WAL引入的性能問題
在一般情況下，WAL會提高SQLite的事務性能；但是在某些極端情況下，卻會導致SQLite事務性能的下降。如：
1.在事務執行時間較長或者要修改的數據量達到GB級的時候，WAL文件會被佔用，它會暫時阻止checkpoint的執行（checkpoint會清空WAL文件），這將導致WAL文件變得很大，增加尋址時間，最終導致讀寫性能的下降。
2.當checkpoint執行的時候，會降低當時的讀寫性能，因此，WAL可能會導致週期性的性能下降。
WAL涉及的接口
# PRAGMA
PRAGMA journal_mode
PRAGMA wal_checkpoint
PRAGMA wal_autocheckpoint
# sqlite
sqlite3_wal_checkpoint
sqlite3_wal_autocheckpoint
sqlite3_wal_hook