文章目录
📕索引底层数据结构与算法
📙索引数据结构
📘二叉树
二叉树数据结构
📘红黑树
红黑树的数据结构
📘Hash
- 对索引的key进行一次hash计算就可以定位出数据存储的位置,很多时候Hash索引要比B+Tree索引更高效
- 仅能满足 "=","IN",不支持范围查询,hash冲突问题。
📘B-Tree
- 索引元素不重复
- 从左到右递增排列。
📘B+Tree
- 非叶子节点不存储data,只存储索引(冗余),可以放更多的索引
- 叶子节点包含所有索引字段
- 叶子节点用指针连接,提高区间访问的性能
- 可以支持范围查询,有双向指针,假如查询Col1>30通过双向指针直接可以查询出来大于30的数据,而不是像B-Tree一样需要重新从根节点查询。
📙表在不同存储引擎的存储结构
📘MyISAM存储引擎索引实现
📚文件结构
- .frm结尾的文件:表结构文件
- .MYD结尾的文件:数据文件
- .MYI结尾的文件:索引文件
📚非聚集索引
假设查询Col1=30,这个时候会先去.MYI结尾的索引文件找到磁盘地址0XF3,然后再去.MYD结尾的数据文件获取这一行数据。索引和数据分开存储就叫做非聚集索引。
📘InnoDB存储引擎索引实现
📚文件结构
- .frm结尾的文件:表结构文件
- .ibd结尾的文件:数据和索引文件,按照B+Tree组织的一个索引结构文件
📚聚集索引
叶节点包含整行记录,例如Col1=30会把其他行(Col2、Col3)的数据放到一起,这就是聚集索引。从结构上来说,聚集索引直接就获取到了整行数据性能比非聚集索引效率更高。
📙为什么DBA总推荐使用整型自增主键做索引
前面提到 InnoDB存储引擎中.ibd文件必须要用B+Tree来组织索引结构。
- 如果表里面有主键,那么就可以直接使用主键作为B+Tree来组织索引结构。
- 如果表里面没有创建主键,它会从表中选择一列所以数据不重复的列作为主键。
- 如果没有选到不重复的列,这个时候MySQL才会自增隐藏列作为主键。
- 通常情况都会自己选择一列作为主键,而不是交由MySQL自增隐藏列,减少MySQL的工作。
选择整型效率更快。
- 如果以字符串作为主键,那么要逐个字符对比ASCII码,这种工作模式在对比过程中,如果二个对比结果前面相同,就最后一个字符不相同,浪费的性能还是很高的。
- 整型存储的空间更小,会节约硬件资源。
假设我先插入8后插入7,即非自增插入数据,这个B+Tree结果是如何变化的呢?
5/6/8这个大节点放满了,插入7
放不下了,进行拆分平衡
假设后面插入9/10这种自增的数据,B+Tree会直接往后面开一个节点,性能比对来说,肯定是自增的会高一些。
📙为什么非主键索引结构叶子节点存储的是主键值?
非主键索引结构叶子节点存储主键值的原因主要有两个:
- 保持一致性:当数据库表进行DML(数据操纵语言,如INSERT、UPDATE、DELETE)操作时,同一行记录的页地址可能会发生改变。由于非主键索引保存的是主键的值,而非实际的数据记录,因此当数据记录发生移动或变更时,非主键索引无需进行更改,只需保持与主键值的对应关系即可,从而保持索引的一致性。
- 节省存储空间:在InnoDB存储引擎中,数据本身已经按照主键索引的B+树结构进行存储。如果非主键索引也存储整行数据,那么每个非主键索引都会存储一份数据,这将导致大量的数据冗余和存储空间的浪费。而只存储主键值的方式可以极大地节省存储空间,因为主键索引已经包含了完整的数据记录。
非主键索引通过存储主键值,可以在查询时通过主键值快速定位到数据记录所在的位置,从而提高查询效率。
先用二级索引找到主键索引,然后使用主键索引回表去查询对应的数据。
📙MySQL最左前缀优化原则是怎么回事
- 先对比name大小,比较字符大小,HanMeimei<Jeff
- 然后对比age大小,比较年龄大小,30<31<32
- 最后对比position大小,dev<manager
bash
EXPLAIN SELECT * FROM employees WHERE name = 'Bill' and age = 31;
EXPLAIN SELECT * FROM employees WHERE age = 30 AND position = 'dev';
EXPLAIN SELECT * FROM employees WHERE position = 'manager';|
根据上述的联合索引,分析上述SQL,只有第一条SQL会走索引。
- 联合索引遵循最左前缀原则,先使用name进行查找,这是name已经排好序了,直接可以查询。
- 然后使用age去查找,发现30,31,32,28,22,30,30,这个是没有排序的,就走全表扫描了。
- 后面就不会使用position继续查找了。