MySQL索引深入理解底层数据结构

8次阅读

共计 762 个字符,预计需要花费 2 分钟才能阅读完成。

定义:索引是帮助 MYSQL 高效 排好序 的数据结构


索引存储在文件里
形式:二叉树 HASH BTREE
为什么用 BTREE 而不用二叉树:


如果每次的数据都是以 1,2,3,4,5,6 的形式添加,会造成二叉树单边增长,从而导致查询效率依然低下
红黑树会自己旋转,会有一个自平衡的过程,但是高度是不可控的,(height), 如果是百万级别的数据,高度是完全不可控的

为什么用 BTREE 而不用 HASH:HASH 如果是单个查找条件会比较快,比如 col=3, 直接用 hash(index=3)即可,但是范围查找的话效率很慢,大部分公司有很多业务都会是范围查找


如果让你来设计 MySQL 的 BTREE,你觉得 degree 设为多少合适?
设为磁盘 I / O 一个节点的值,假如一次 I / O 最多取 4k, 就设为 4k,作均衡
B+TREE 的优势:非叶子节点不存储数据,只存储 key

评价一个索引结构好坏的标准: 磁盘 I / O 次数
预读:磁盘一般会顺序向后读取一定长度的数据(页的整倍数)放入内存
局部性原理: 如果一个数据被用到了,那他附近的数据也马上会被用到
B+TREE 的度一般会超过 100,所以高度 h 会非常小(一般在 3 - 5 之间)
MyISAM 索引实现:MyISAM 索引文件和数据文件是分离的 存储引擎是表级别,不是数据库级别


D–>Data I–>index
InnoDB–> 聚集索引 –> 数据和索引是放在一起的 –> 是按主键索引构建的一个 BTREE 树
InnoDB–> 推荐使用整型自增主键 –> 保证数据可以顺序插入到当前索引节点的后续位置,如果是用 UUID,需要比较 ASCII 码,还有可能插入的地方空间不足需要分裂开,花费更多的时间
不建议使用过长的字段作为主键,因为所有辅助索引都引用主索引,过长的主索引会令辅助索引变得过大
为什么非主键索引结构叶子节点存储的是主键值?(一致性和节省存储空间)

正文完
 0