1. 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".

2. 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.

3. B+-trees 33 is the smallest value stored in the subtree to its right48 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.

4. 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.

5. 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.

6. 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.