Why use B+ number in Mysql index structure

Preface

In MySQL, whether it is Innodb or MyIsam, B+ tree is used as an index structure (other indexes such as hash are not considered here). This article will start with the most common binary search tree, and explain the problems solved by various trees and the new problems they face step by step, so as to explain why MySQL chooses B+ tree as the index structure. Organized a 328-page MySQL PDF document

1. Binary search tree (BST): unbalanced

Binary Search Tree (BST, Binary Search Tree), also called binary sorting tree, needs to meet on the basis of binary tree: all node values ​​on the left subtree of any node are not greater than the value of the root node, and the right subtree of any node The value of all nodes above is not less than the value of the root node. The following is a BST:

When a quick search is required, storing the data in the BST is a common choice, because the query time depends on the tree height, and the average time complexity is O(lgn). However, BST may become unbalanced due to long distortion, as shown in the following figure, at this time BST degenerates into a linked list, and the time complexity degenerates to O(n).

To solve this problem, a balanced binary tree was introduced.

2. Balanced Binary Tree (AVL): Rotation takes time

The AVL tree is a strictly balanced binary tree. The height difference between the left and right subtrees of all nodes cannot exceed 1; the search, insertion and deletion of the AVL tree are all O(lgn) in the average and worst cases.

The key to AVL to achieve balance lies in the rotation operation: insertion and deletion may disrupt the balance of the binary tree, and at this time, it is necessary to rebalance the tree through one or more tree rotations. When inserting data, only one rotation (single rotation or double rotation) is required at most; but when deleting data, the tree will become unbalanced. AVL needs to maintain the balance of all nodes on the path from the deleted node to the root node. Rotation The magnitude of is O(lgn).

Due to the time-consuming rotation, the AVL tree is very inefficient when deleting data; when there are many deletion operations, the cost of maintaining balance may be higher than the benefits it brings, so AVL is not widely used in practice.

3. Red and black trees: the tree is too high

Compared with the AVL tree, the red-black tree does not pursue a strict balance, but a rough balance: it just ensures that the longest possible path from root to leaf is not more than twice as long as the shortest possible path. From the implementation point of view, the biggest feature of the red-black tree is that each node belongs to one of two colors (red or black), and the division of node colors needs to meet specific rules (the specific rules are omitted). Examples of red-black trees are as follows:

Compared with the AVL tree, the query efficiency of the red-black tree will be reduced, because the balance of the tree becomes worse and the height is higher. However, the deletion efficiency of the red-black tree is greatly improved, because the red-black tree also introduces colors. When inserting or deleting data, only O(1) rotations and color changes are required to ensure the basic balance. No need like AVL The tree rotates O(lgn) times. In general, the statistical performance of red-black trees is higher than AVL.

Therefore, in practical applications, the use of AVL trees is relatively small, while the use of red-black trees is very extensive. For example, TreeMap in Java uses red-black trees to store sort key-value pairs; HashMap in Java8 uses linked list + red-black tree to solve hash conflict problems (when there are fewer conflicting nodes, use linked list, when there are many conflicting nodes, use red Black tree).

For data in memory (such as the TreeMap and HashMap above), the performance of the red-black tree is very excellent. But for the case of data in auxiliary storage devices such as disks (such as databases such as MySQL), the red-black tree is not good at it, because the red-black tree is still too tall. When the data is in the disk, disk IO will become the biggest performance bottleneck. The design goal should be to minimize the number of IOs; and the higher the tree height, the more IO times required for addition, deletion, modification, and checking, which will seriously affect performance.

Four, B tree: born for the disk

B-tree, also known as B-tree (not the minus sign), is a multi-way balanced search tree designed for auxiliary storage devices such as disks. Compared with a binary tree, each non-leaf node of the tree can have multiple subtrees. Therefore, when the total number of nodes is the same, the height of the B tree is much smaller than the AVL tree and the red-black tree (the B tree is a "short fat man"), and the number of disk IOs is greatly reduced.

The most important concept to define a B-tree is the order. For a B-tree of order m, the following conditions need to be met:

• Each node contains at most m child nodes.

• If the root node contains child nodes, it contains at least 2 child nodes; except for the root node, each non-leaf node contains at least m/2 child nodes.

• A non-leaf node with k child nodes will contain k-1 records.

• All leaf nodes are in the same layer.

It can be seen that the definition of B-tree mainly restricts the number of child nodes and the number of records of non-leaf nodes.

The following figure is an example of a 3-order B-tree:

In addition to the small height of the tree, the advantage of the B-tree is the use of the principle of access locality. The so-called principle of locality means that when a piece of data is used, the nearby data has a greater probability of being used in a short time. The B-tree stores data with similar keys in the same node. When accessing one of the data, the database will read the entire node into the cache; when the adjacent data is accessed immediately, it can be read directly in the cache , No disk IO is required; in other words, the cache hit rate of the B-tree is higher.

B-tree has some applications in the database, such as mongodb index uses the B-tree structure. But in many database applications, the B+ tree, a variant of the B tree, is used.

Five, B+ tree

B+ tree is also a multi-way balanced search tree, and the main difference from B tree is:

• Each node in the B-tree (including leaf nodes and non-leaf nodes) stores real data. In the B+ tree, only leaf nodes store real data, and non-leaf nodes only store keys. In MySQL, the real data mentioned here may be all the data of the row (such as the clustered index of Innodb), or it may be just the primary key of the row (such as the secondary index of Innodb), or the address of the row (such as MyIsam Non-clustered index).

• A record in the B tree will only appear once and will not appear repeatedly, while the key of the B+ tree may appear repeatedly-it must appear in leaf nodes, or it may appear repeatedly in non-leaf nodes.

• The leaf nodes of the B+ tree are linked by a doubly linked list.

• For non-leaf nodes in the B-tree, the number of records is 1 less than the number of child nodes; while the number of records in the B+ tree is the same as the number of child nodes.

Therefore, compared with B-tree, B+ tree has the following advantages:

• Fewer IO times: The non-leaf nodes of the B+ tree contain only keys and no real data, so the number of records stored in each node is much more than the number of B (that is, the order m is greater), so the height of the B+ tree is higher Low, fewer IO times are required for access. In addition, since each node stores more records, the principle of access locality is better utilized, and the cache hit rate is higher.

• More suitable for range query: When performing range query in B-tree, first find the lower limit to be searched, and then traverse the B-tree in order until the upper limit is found; while for B+ tree range query, only need to traverse the linked list That's it.

• More stable query efficiency: The query time complexity of the B-tree is between 1 and the tree height (corresponding to the root node and leaf node respectively), while the query complexity of the B+ tree is stable to the tree height, because all the data is in Leaf node.

The B+ tree also has its disadvantages: because the keys will be repeated, it will take up more space. However, compared with the performance advantages it brings, the space disadvantages are often acceptable. Therefore, B+ trees are more widely used in databases than B trees.

6. Feel the power of B+ tree

As mentioned earlier, the biggest advantage of B-tree/B+ tree over binary trees such as red-black trees is that the tree height is smaller. In fact, for Innodb's B+ index, the height of the tree is generally 2-4 levels. Let's make some specific estimates.

The height of the tree is determined by the order, the larger the order, the shorter the tree; and the size of the order depends on how many records each node can store. Each node in Innodb uses a page (page), the size of the page is 16KB, of which metadata only occupies about 128 bytes (including file management header information, page header information, etc.), most of the space is used to store data .

• For non-leaf nodes, the record only contains the key of the index and the pointer to the next node. Assuming that each non-leaf node page stores 1000 records, each record occupies approximately 16 bytes; this assumption is reasonable when the index is an integer or a shorter string. To extend it, we often hear suggestions that the length of the index column should not be too large. This is the reason: the index column is too long, and the number of records contained in each node is too small, which will cause the tree to be too high and the effect of the index will be greatly reduced. And the index will waste more space.

• For leaf nodes, the record contains the key and value of the index (the value may be the primary key of the row, the complete data of a row, etc., see the above for details), and the amount of data is larger. It is assumed that each leaf node page stores 100 records (in fact, when the index is a clustered index, this number may be less than 100; when the index is a secondary index, this number may be much greater than 100; it can be estimated according to the actual situation) .

For a 3-layer B+ tree, the first layer (root node) has 1 page and can store 1000 records; the second layer has 1000 pages and can store 1000 1000 records; the third layer (leaf node) has 1000 1000 pages, each page can store 100 records, so it can store 1000 1000 100 records, that is, 100 million. For a binary tree, it takes about 26 layers to store 100 million records.

Seven, summary

Finally, summarize the problems solved by various trees and the new problems they face:

1. Binary search tree (BST): solves the basic problem of sorting, but due to the inability to guarantee balance, it may degenerate into a linked list;

2. Balanced Binary Tree (AVL): The problem of balance is solved by rotation, but the efficiency of the rotation operation is too low;

3. Red-black tree: By abandoning strict balance and introducing red and black nodes, the problem of low AVL rotation efficiency is solved. However, in scenarios such as disks, the tree is still too high, and the number of IOs is too much to organize a 328-page MySQL PDF document ;

4. B-tree: By changing the binary tree to a multi-path balanced search tree, the problem of too high a tree is solved;

5. B+ tree: On the basis of the B tree, the non-leaf nodes are transformed into pure index nodes that do not store data, which further reduces the height of the tree; in addition, the leaf nodes are connected into a linked list using pointers, and the range query is more efficient.