为什么索引结构默认使用B+Tree？为什么需要注意联合索引中的顺序？最左前缀原则是什么？

（1）为什么索引结构默认使用B+Tree，而不是B-Tree，Hash，二叉树，红黑树？

B-tree：B+Tree相比于B-Tree，所有的数据都存储在叶子节点，并且叶子节点之间用指针相连形成了一个有序链表，这有利于范围查询和全表扫描时连续地读取磁盘上的数据，极大地降低了磁盘I/O次数。而在B-Tree中，数据分布在所有节点，不利于范围查询，IO代价高。

Hash：虽然可以快速定位，但是没有顺序，适合等值查询，不支持范围查询；基于Hash表实现，只有Memory存储引擎支持哈希索引；如果有大量重复键值得情况下，哈希索引的效率会很低，因为存在哈希碰撞问题。

二叉树：树的高度不均匀，不能自平衡，在大规模数据插入后容易退化为链表形式，导致深度增大，查找效率变低，并且IO代价高，不适合磁盘存储。

红黑树：虽然保证了平衡性，但它仍然可能导致树的高度随着数据量的增长而增加，同样面临较多的磁盘I/O问题。同时，红黑树的每个节点存储的数据有限，对于大数据量的场景，其索引体积可能过大，不便于范围查询。

（2）联合索引是什么？为什么需要注意联合索引中的顺序？

MySQL可以使用多个字段同时建立一个索引，叫做联合索引。在联合索引中，如果想要命中索引，需要按照建立索引时的字段顺序挨个使用，否则无法命中索引。假设现在建立了"name，age"的联合索引，那么索引的排序是，先按照name排序，如果name相同，则按照age排序。一般情况下，将查询需求频繁或者字段选择性高的列放在前面。

（3）MySQL的最左前缀原则是什么？

最左前缀原则就是最左优先，在创建多列索引时，要根据业务需求，where子句中使用最频繁的一列放在最左边。MySQL 会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配。

补充：前缀索引是什么？

索引的字段可能非常长，这样既占内存空间，也不利于维护。所以，我们就只把很长字段的前面的公共部分作为一个索引，提高索引效率。但是，order by不支持前缀索引。