B+-trees In practice, B-trees are not used much as defined earlier. The B+-tree variation is the one most commonly implemented. In a B-tree, pointers to records are located at internal nodes and at leaves. In a B+-tree, pointers to records are located in the leaves only. Leaves contain (pointers to) all records and are linked sequentially to form a singly-linked sorted list. Internal nodes contain values that guide the search towards the leaves. The part of the tree consisting of the internal nodes is called the "index set".

B+-trees B+-trees make it easy to support "range search" operations. E.g. Find all records whose key is between x and y. This is because we can access all records in a (sorted) linear order. Locate x and then follow simple links all the way to y. We usually try to limit the number of levels to 3. If we can also manage to store the root in main memory, we'll only need to do 2 I/O operations to access a record.

B+-trees 33 is the smallest value stored in the subtree to its right 48 60 11 21 2 6 9 11 14 19 21 30 32 33 35 46 48 51 57 60 80 33 is the smallest value stored in the subtree to its right 60 is the smallest value stored in the subtree to its right.

B+-trees Insert and delete operations are similar to those in the standard B-tree. How inefficient is a split? In theory, a sequence of splits can slow down the insert operation significantly. In practice, it is very rare to split all the way to the root (why?) We may also modify leaf insertions to avoid splitting by allowing adoptions from siblings.

B+-trees Insert and delete operations are similar to those in the standard B-tree. Do we really need to merge after deleting a record? We may decide to not bother with a merge and instead accept the existence of an underflow. Reasons: Delete operations are typically few. It's highly likely there will be an insert operation soon and the underflow reversed.

B+-trees Insert and delete operations are similar to those in the standard B-tree. Do we really need to modify the index after a delete? We may decide to not remove the copy of the deleted key from the index. Reason: The key still separates the entries correctly. However, if, later on, we end up merging, then keys must be adjusted.