数据库索引（本质是一个数据结构）
正确合适的索引是数据库性能优化得基石
数据库索引是一种为了加速数据表中记录检索的数据结构
数据库的索引存储在磁盘中 不是存储在内存之中
索引查询过程
当数据变得很多 查询性能会非常的差 因为索引是存放在磁盘中 操作系统和磁盘的交互是非常浪费性能的
使用 索引就非常的快捷
把索引 和要查询的id列单独拿出来放在一个数据结构中 关键字即是id对应索引（也就是磁盘地址）
然后在数据结构中进行查询 返回查询到的磁盘指针
然后数据库根据传回来的磁盘指针 快速检索到这个磁盘指针对应的位置的数据然后返回给请求端
查询效率由O（n） 变成了O（对应的数据结构的复杂度）
因为各种数据数据结构的复杂度不同 有的复杂有的简单
而索引的性能取决于数据结构
用的最多的数据结构
哈希表 哈希索引
特点 等值匹配非常快 但是不支持范围查询
传进来的关键词经过hash的散列计算 值不能都得到保证 所以它没办法支持范围查询
intetp不支持用户级别的创建 自适应哈希索引
为什么会转化为树？
因为链表是O（n）的复杂度 它查询的时候会一个个的向等下去找 效率比较慢
为什么哈希索引作为数据结构能够提高检索速度呢？
得益于它的第一层结构是数组
基于你存进的关键字 然后用一个哈希算法进行改造 然后根据数组的长度进行计算 最后得到数组的下标
拿到下标就可以在数组中很快的拿到一个元素 速度极快 复杂度O（1）
如果下标对应的是一个链表 也就是一个O（n）的比对过程
如果是一个红黑树 用过二分递归查找的方式查找 也就是O（logn）的比对过程
树 B + 树索引
可以得到数据性能提升 但是如果数据组织出现问题效率就会变慢，比如说数据是一个1 2 3 4 5 6这种结构 数据组织就成为了一个链表
所以到了平衡二叉树 AVL树
平衡二叉树在数据组织阶段通过左旋保持平衡二叉树的结构
存储的结构变成了一个磁盘块
关键字
数据区 有两种方案 一是存储对应数据的指针 而是存储这条行记录所有的数据
子节点的引用 通过子节点的引用找寻下一个要比对的数据进行比对
每一次的比对都需要进行操作系统和磁盘的交互 树的高度越高 要比对的次数就越多 性能也就越差
IO是操作系统和磁盘的交互的简写
操作系统和磁盘的交互是以系统页为基本单位 一页也就是4kb
而一个磁盘块是远远填充不满一页的 一次交互拿来的一页只有一个磁盘块
IO的利用率太低
所以要解决树高的问题
就到了B - 树结构 （多路平衡查找树）
为了保证树的绝对平衡 通过节点的和平和分裂保证树的绝对平衡 经常变化的列不宜创建索引
解决了上面树的浪费空间和树高效率低的问题
把磁盘块的大小固定 为数据库页 一页数据库页的大小默认为16KB
然后向里面放关键字 直到放不下 这样就能在很低的高度存放很多的关键字
（空间换时间）
根据关键子把数据划分了多个区间
n个关键字就有n + 1个区间
B树结构中
关键子key的个数 = 子岔路degree - 1
最后
根据数据区获得数据
为什么MySQL不使用B -树结构而使用B+树？
这就到了B + 树
跟节点和支节点数据区全部不见 全部到了最下面的叶子节点
数据匹配的规则变为了左闭合方式
（ 1 28 66 1<=X < 28 P1区间 28=<X <66 P2区间 66<X P3区间）这样能保证一定会搜寻到最末尾的叶子节点好寻找数据区
而最下面的节点组成了一个双向链表结构
排序
IO利用率更高 IO性能更强劲 上面的B树还是会造成数据区的浪费 而B+树的根节点和支节点不存放数据区 充分利用了操作系统和磁盘交互页的内存
基于索引的数据扫描 B+树更好
只需要扫描最末尾的叶子节点
查询效果更稳定 有几层就会进行几次IO次数 查询效率更稳定
