What is cache line alignment strategy for database block structures?
In the world of high-frequency trading and high-performance databases, the difference between a sub-millisecond query and a bottlenecked one often comes down to Cache Line Alignment.
While a database "block" (typically 8KB) is the unit of storage on disk, the CPU thinks in 64-byte Cache Lines. If your database internal structures—like headers, latches, or index entries—are not aligned to these 64-byte boundaries, the hardware is forced to do twice the work for a single piece of data.
A CPU fetches data from RAM in 64-byte chunks. If a critical data structure (like a 16-byte Mutex) starts at byte 60 of a cache line:
The Problem: The first 4 bytes sit in Cache Line A, and the remaining 12 bytes sit in Cache Line B.
The Penalty: To read that single 16-byte structure, the CPU must perform two memory fetches, consume two slots in the L1 cache, and manage two sets of coherency metadata. If this is a "hot" structure, you’ve just halved your memory bandwidth.
The most critical part of a database block to align is the Header.
The Strategy: Ensure that the "Hot" metadata—the block SCN (System Change Number), the transaction table, and the free-space pointers—are packed into the first 64-byte segment.
The Goal: When the Log Writer or a foreground process touches a block, the hardware prefetcher pulls in that first 64-byte line. If all the "management" data is in that one line, the CPU never has to go back to RAM for the rest of the metadata.
As we discussed in previous blogs, False Sharing happens when two different cores try to update different variables that live on the same cache line.
The Strategy: If you have two "Hot" counters (e.g., reads and writes) that are updated by different threads, you must Pad them.
The Implementation: You insert "dummy" bytes between the variables to ensure they sit on separate 64-byte boundaries.
Example:
long counter1; char padding[56]; long counter2;
Result: Each core gets its own private cache line, allowing them to update the counters in parallel without triggering a "Cache Line Ping-Pong."
| Structure | Alignment Strategy | Benefit |
| B-Tree Index Nodes | Align "keys" to 16-byte boundaries within the 64-byte line. | Enables SIMD (Single Instruction, Multiple Data) searching across keys. |
| Transaction Slots | Ensure each slot does not straddle a 64-byte boundary. | Prevents multiple transactions from fighting over the same cache line coherency. |
| Redo Log Buffers | Align start of entries to 64 bytes. | Maximizes Write Combining efficiency for sequential bursts. |
If you are writing C/C++ for a database engine or a custom extension, you don't leave alignment to chance:
Compiler Directives: Use __attribute__((aligned(64))) in GCC or alignas(64) in C++11.
Memory Allocation: Use posix_memalign() instead of malloc(). This ensures the starting address of your buffer is a multiple of 64.
Structure Reordering: Place the most frequently accessed ("Hot") members at the top of the struct and less frequent ("Cold") members at the bottom to ensure they don't share cache lines.
Cache line alignment is the "last mile" of database optimization. By ensuring your internal structures "fit" into the 64-byte windows the CPU uses to view the world, you eliminate redundant memory fetches and dramatically reduce cache-coherency overhead. In a high-concurrency environment, an aligned structure is the difference between linear scaling and a "performance ceiling."