- 为了减少IO，索引树会一次性加载吗 不会，有如下原因：
数据库索引是存储在磁盘上，如果数据量很大，必然导致索引的大小也会很大，超过几个G。当我们利用索引查询时候，是不可能将全部几个G的索引都加载到内存中，而是逐一加载每一个磁盘页，因为磁盘页对应着索引树的节点。
-
为何说B+树一般查找行记录，最多只需1-3次磁盘IO InnoDB存储引擎中页的大小为16KB，一般表的主键类型为INT（占用4个字节）或BIGINT（占用8个字节），指针类型一般为4或8个字节，即一个页中大概存储16KB/(8+8)约等于1000个键值。假设一个数据页存储1000条行记录数据，一个深度为3的B+树可以维护100010001000=10亿条记录，满足日常的基本需求。然而实际情况中每个节点可能不会填充满，因此在数据库中，B+树的高度一般为2-4层。Mysql中的InnoDB存储引擎在设计时是将根节点常驻内存的，即查找某一行键值的行记录时最多需要1-3次磁盘IO操作。
-
为什么说B+树比B树更适合实际应用中操作系统的文件索引和数据库索引 （1）B+树的磁盘读写代价更低
B+树的内部节点并没有指向关键字具体信息的指针。因此其内部节点相对B树更小。它的树的深度比同样数据量的B树更矮胖，IO读写的次数也就降低了。
（2）B+树的查询效率更稳定 B+树相对B树而言，它只有叶子节点存储记录，所有关键字查询的路径长度相同，每一个数据与的查询效率相当。而B树非叶子节点和叶子节点都存储关键字记录，有时查找一条关键字记录，B树每次查询的路径长度都不相同，效率不稳定。
- hash索引与B+树索引的区别 （1）hash索引不能进行范围查询，而B+树可以。因为hash索引指向的数据是无序的，而B+树的叶子节点是个有序的链表。
（2）hash索引不支持联合索引的最左侧原则（即联合索引的部分索引无法使用），B+树可以。对于联合索引来说，hash索引在计算hash值的时候是将索引键合并后一起再计算hash值，所以不会针对每个索引单独计算hash值。因此如果用到联合索引的一个或者几个索引时，联合索引无法被利用。
（3）hash索引不支持order by排序，因为hash索引指向的数据是无序的，因此无法起到排序优化的作用，而B+树索引数据是有序的，可以起到对该字段order by排序优化的作用。同理，我们也无法使用hash索引进行模糊查询，而B+树使用like进行模糊查询的时候，like后面模糊查询（比如%结尾）的话就可以起到优化作用。
（4）InnoDB不支持哈希索引。
