[Interview] Why live MySQL database storage to use B + tree index?
hash index o (1) B + tree index o (logn)
Why red-black tree there, because in some cases prevent binary sort tree degenerates into a linked list - the birth of a balanced binary sort tree - the tree of performance depends on the height of the tree
Why use a DB M-way B-tree, in order to further reduce the height of the tree, reducing the number of db disk io, if in memory, higher efficiency red-black tree
M Why not infinite, because it will degenerate into an ordered array, not into memory at once, B tree is a node can be loaded once
B + tree on the basis of the B-tree, (1) only the data stored in the leaf node tree height greater --B; (2) while the leaf node list - to avoid cross-layer range lookup
Why not hash index (1) select multiple (2) the index is generally on the disk, large volumes of data may not be the case once loaded into memory B + tree design can allow data to load batches, while the lower height of the tree, less disk io times and improve search efficiency
There is an article,
Interviewer: Why do you want to use MySQL index B + tree, rather than the other trees? For example, B-tree?
https://www.cnblogs.com/sujing/p/11110292.html
1、B-Tree因为非叶子结点也保存具体数据，所以在查找某个关键字的时候找到即可返回。而B+Tree所有的数据都在叶子结点，每次查找都得到叶子结点。所以在同样高度的B-Tree和B+Tree中，B-Tree查找某个关键字的效率更高。
2、由于B+Tree所有的数据都在叶子结点，并且结点之间有指针连接，在找大于某个关键字或者小于某个关键字的数据的时候，B+Tree只需要找到该关键字然后沿着链表遍历就可以了，而B-Tree还需要遍历该关键字结点的根结点去搜索。
3、由于B-Tree的每个结点（这里的结点可以理解为一个数据页）都存储主键+实际数据，而B+Tree非叶子结点只存储关键字信息，而每个页的大小有限是有限的，所以同一页能存储的B-Tree的数据会比B+Tree存储的更少。这样同样总量的数据，B-Tree的深度会更大，增大查询时的磁盘I/O次数，进而影响查询效率。