The Write-Ahead Log (WAL) Makes a Write Cost More Than a Read
Before the database changes a page in memory, it first writes a record of that change to a sequential log on durable storage, so a crash can be recovered by replaying the log. That is why a committed write must wait for a real disk flush while a read can often be satisfied from memory, and why bulk updates generate far more I/O than their row count suggests. It also explains why batching many small writes into one transaction is so much faster than committing each one separately.
Questions this Concept answers
- Why does a committed write have to wait for storage while a read often does not?
How a Write-Ahead Log Makes Committed Database Writes Survive a Crash
A write-ahead log (WAL) secures durability by an ordering rule: before any modification is applied to the real on-disk data structures, a compact record describing that change is appended to a separa…