MySQL索引底层数据结构与算法

1、索引的数据结构

1.1、二叉树

1.2、红黑树(二叉平衡树）

1.3、hash表

对key进行一次hash计算就可以定位出数据存储的位置

问题：hash冲突问题、仅满足=和in的查找，不支持范围查找  

1.4、B-tree

1.5、B+ tree

非叶子节点不存储data，只存储索引（冗余），可以放更多的索引

叶子结点用指针连接，提高区间访问的性能

inodb-page-size=16kb 

2、MyISM存储引擎索引实现

索引文件和数据文件是分离的（非聚集）

3、InnoDB索引实现（聚集）

3.1、表数据文件本身就是按B+Tree组织的一个索引结构文件

3.2、聚集索引-叶节点包含了完整的数据记录

3.3、为什么建议InnoDB表必须建主键，并且推荐使用整型的自增主键？

答：B+树的存储结构决定的，如果没有，架构会自动创建一个隐藏的主键；整形在比较大小时速度快，数据结构保存比较节省空间；存储时不需要向叶子中间插入数据，重新平衡树，节省时间。

3.4、为什么非主键索引结构叶子节点存储的是主键值？(一致性和节省存储空间)

4、索引最左前缀原理

4.1、复合索引的结构
复合索引是由多个列组成的索引，例如一个索引定义为 (col1, col2, col3)。在索引结构中，数据会按照 col1 排序，如果 col1 相同，则按照 col2 排序，以此类推。

4.2、查询条件的匹配规则

• 如果查询条件中包含 col1，例如 WHERE col1 = 'A'，则索引可以被使用。
• 如果查询条件中包含 col1 和 col2，例如 WHERE col1 = 'A' AND col2 = 'B'，则索引也可以被使用。
• 如果查询条件中包含 col1、col2 和 col3，例如 WHERE col1 = 'A' AND col2 = 'B' AND col3 = 'C'，则索引可以被完全利用。
• 如果查询条件中跳过 col1，例如 WHERE col2 = 'B'，则索引无法被使用，因为查询条件没有从最左列开始。
• 如果查询条件中跳过 col2，例如 WHERE col1 = 'A' AND col3 = 'C'，则索引只能部分使用，即只能利用 col1 的部分，而 col3 无法被索引优化。