MySQL 为什么选择 B + 树作为索引的数据结构，为什么不用 B 树？二叉树？哈希？

我们这里简单计算一下三层的B + 树能存储多少记录。这里以聚簇索引来举例。

B + 树的根节点也是一个数据页，大小为 16 k，非叶子节点存储主键 bigint，大小为 8 个字节 + 一个指针大小为6 个字节，每一条数据就是 8 + 6，14 个字节，所以一个数据页能存储 16 * 1024 / 14，为了好计算，这里就约等于1000。
第二层就有 1000 个数据页，第三层就有 1000 * 1000 个数据页，也就是 1000000，1 百万个数据页。

一个数据页能存储多少行记录呢？

当然这里没有考虑页头，目录，页尾的占用情况，假设一个完整的行记录大小为1 kb，那么一个数据页就能存储16行记录，那么三层B + 树，就能存储 1 百万 * 16 行记录，也就是 1千6百万行数据。假设一个完整的行记录大小为16kb，那么一个数据页就只能存储一个行记录，那么三层B + 树，就只能存储 1 百万行记录。

由此看见，设计表的时候，考虑一行记录的大小是多么的重要，要按照业务需求，严格控制字段的大小。

回到问题，如果使用B 树，假设一个完整的行记录大小为1kb，那么一个数据页就能存储16行记录。
第二层就是 16 个数据页，第三层就是 16 * 16，也就是256 个 数据页， 那么三层 B 树，就只能存储 256 * 16，也就是 4096 行数据。要存储 2千万行数据，B 树得多少层啊。那得多少次磁盘IO啊。
如果采用二叉树作为索引的数据结构，同理B树，而且二叉树，还不如B树呢。B树好歹还是多叉树，而你二叉树，只有两个叉。

为什么不使用 Hash 作为索引的数据结构？Hash 时间复杂度不是 O（1）吗？查询速度不是很快吗？

如果采用哈希作为索引的数据结构，那么模糊查询，哈希怎么支持？比如，like"张%"，你哈希怎么计算哈希值？你哈希怎么支持范围查询？所以哈希就被pass掉了。哈希无法支持模糊查询，范围查询。