B站课程地址
P2.索引的本质, 可以减少磁盘IO次数
链表: 一条链子, 全表扫描二叉树: 每个节点下面有两个节点, 大的往右边叉, 小的往左边叉红黑树: 高级一点的二叉树, 会重新排列 (二叉平衡树)
红黑树, mysql没有选择这种结构, 因为树状结构, 当数据量大的时候, 查询IO次数非常多
于是想办法将树的层数控制在三四层的情况下, 增加每个节点存储的数据, 这种结构叫做 B树
P3.B+树结构讲解
MySQL用的是加强版的B树, 叫做B+树
- 这里注意一下, 这里就是一整棵树, 图示这里是三层的树,
- 只有最下层的树(页子节点)才存储有data, 每个节点的最大存储大小是16kb
- 非页子节点(枝干层)保存的是冗余的索引, 相当于村长家保存有
部分村里人的名字和地址 - 索引的是按照从小到大来 从左到右排序的 15->18->20->30
- 取值(data)的方式: 如上图, 比如现在索引的值是16
- 第一次获取, 落在第一层的15-56中, 按照箭头进入对应的第二层
- 第二次获取, 落在第二层的15-20中, 按照箭头进入对应的第三层
- 第三次获取, 获取到索引为15的data. 完成查询, 从磁盘读取到内存中
P4.Myisam引擎的索引实现
P5.InnodeDB引擎的索引实现
InnoDB的聚集索引, 直接在索引文件中存储数据, 索引更快.
如果通过二级索引查询, 类似于index, 需要回表
P6.为什么不用uuid, 而是用整型的自增ID
第三点, 所以最好不要用uuid(字符串), 而是用整形自增ID, 原因:
- 因为二叉树比大小, 数字具有优势
- 自增的话, 往往直接往二叉树的右边添加数据, 不会使节点分裂(那棵树的结构要重新排列)
另外一种数据结构, Hash哈希: 由一维数组+二维链表组成. 基本上不用, 而是用B+tree, 原因:
- 仅能满足 = , IN, 不支持范围查询
- Hash冲突问题
B+树为什么能进行索引范围查找呢, 原因
B+树的页子节点, 存储了相邻节点的磁盘位置, 这也是B+树和B树的区别
P7.联合索引的底层结构(最左原则的原理: 索引结构的排列)
联合索引的结构↓
思考下面这3个sql, 哪几个会走索引?
1. 正确结果只有第一条SQL会走索引, 最左原则:
-
一定要从第1个字段开始
-
不能跳过左边任意一个字段, 查后面的
2. 为什么会这样呢, 因为在于索引的排序, 看上图, 先排的Name, 再排的age
第二条SQL, 你查age=30的值, 你在第一页看到的是30,31,32. 但是第二页还可能有等于30的,无法预测,索引失效
第一条SQL, 你先查出name=Bill的, 再查age=31, 此时你很确定第二页中没有你要的数据了, 因为已经限定了name=Bill
