In a B+ tree index, how is the data kept sorted for efficient searching?
Think about where actual records or pointers to records are stored in a B+ tree.
B+ trees store all actual data pointers in the leaf nodes, which are linked in sorted order. Internal nodes only store keys to guide the search.
Given a B+ tree of order 4 (maximum 4 children per node), what is the maximum number of keys a single internal node can hold?
Remember, the number of keys in an internal node is one less than the number of children.
For a B+ tree of order m, each internal node can have up to m children and thus m-1 keys.
When inserting a new key into a full leaf node in a B+ tree of order 3, which option correctly shows the resulting split?
Initial leaf node keys: [10, 20, 30] Insert key: 25 Order: 3 (max 3 children, max 2 keys per node)
Recall that after splitting, the middle key is promoted to the parent node.
Inserting 25 into [10,20,30] causes overflow. Splitting into [10,20] and [25,30] with 25 promoted maintains order and balance.
You want to optimize a B+ tree index for a disk block size of 4KB. Which factor is most important when choosing the order of the B+ tree?
Think about how disk reads work and how node size relates to block size.
Choosing an order that fills a disk block fully reduces the number of disk reads needed, improving performance.
Given a B+ tree search algorithm that always moves to the leftmost child if the key is less than the first key in the node, what is the likely cause of missing keys during search?
Consider how B+ tree internal nodes guide the search to the correct child.
B+ tree search must choose the correct child pointer based on key comparisons, not always the leftmost child. Otherwise, keys can be missed.