关于数据库索引引发的问题：
索引是什么 为什么需要索引 索引怎么起作用 如何高效的存取数据呢？
线性结构
将数据存在线性结构的容器中
缺陷：数据量小时问题不是很大，但是一旦数据很大时，需要串行查找，效率是十分低的。 二叉查找树 为了提高效率，使用二叉查找树来存储数据
这样我们查找id = 6,id = 9的数据就不用从链式找下来，找到相对应的层级次数即可 在一棵树中找到目标数据所需比较的次数 = 目标数据所在的层级 使用二叉平衡树查找42亿数据，最差的情况只需要32次 2^32 = 42亿。查找效率十分明显。
为什么在线性结构中不用二分查找呢？
不能用二分查找，对于线性结构的数据集合，如果使用二分查找的话，就需要把所有数据都加载到内存中，这样的内存是非常恐怖的，而数据在逻辑上天然支持二分查找。
树的结构：
二叉查找树 二叉平衡树 平衡树 B树 B+树 二叉平衡树 二叉平衡树会在数据插入完毕后自动调整节点，使树的层级不会太深 在内存中查找数据是非常快的，而前提是把所有的数据加载到内存中
而表数据量很大，而且需要持化话，一般来说是不会放在缓存中的，而是存在磁盘中，等需要使用时在从磁盘加载到内存，也就是涉及到磁盘-内存的IO操作
把500w行数据一次性加载到内存中进行二分查找，内存一般会不足的，所以我们组织数据库的方式是： 把数据存在磁盘中 数据按树结构组织 查询时分块读取并比较，持续进行磁盘IO读取节点，直到找到目标数据
每个节点存储‘一小块数据’，每次IO读取一个节点，分多次IO读取每一块数据到内存判断，直到找到最匹配的数据。
二叉平衡树和磁盘IO 数据存储在磁盘中--没问题 数据按照树结构组织--没问题 查询时分块读取数据--磁盘IO次数过多的话会很慢
网络IO和磁盘IO是非常慢的
B树
当考虑磁盘IO时，二叉平衡树在数据量庞大的时候也会进行多次磁盘IO，考虑数据丢失和持久化，不方便把所有数据都放入内存，让其在内存中查找。
影响磁盘IO的原因：树的深度（层级）
问题变成如何让树变矮，减少树的层级呢？ 增加树节点存储数据的量
N阶B树，每个节点最多可存N-1个数据 每个节点最多可连N个子节点
这样组织数据的好处：每次加载出一个节点时都可以从磁盘带出更多条数据，从而减少树的层级，减少磁盘IO的次数 空间换时间
如何实现这种结果，让数据库表中的数据组织成B树的结构呢？
举个例子，当我要找id=7的数据时，需要先找到根节点，和id=4的节点比较，由于7>4，所以选择右侧那一支，接着因为6<7<8，所以这个节点中三个addr选择中间的addr，顺着这个地址找到7的节点，然后取出数据。
当一个节点的数据被加载到内存中后，节点内部的数据在内存中二分查找是非常快的。
B+树与索引
Mysql索引使用的是B+树 为什么不用B树呢？ B树的每个节点存储的都是完整的数据，当节点存储空间固定时，完整的数据越大，节点中存储的数据就越少，导致层级变深
有没有什么用一个标识就表示一行数据呢？有 主键 B＋树则是除叶子节点存储完整的数据外，非叶子节点的数据结构为索引加地址，这样节点就能存储更多的数据了，使树的层级减少，且叶子节点使用了双向链表，使用where 范围查找时会十分方便
操作系统中页的概念，是用来存储数据的一种单位，大小为4k，Mysql中也有页的概念，大小为16k，Mysql中页对应B树中一个个节点，即节点存储空间固定
如何使树层级减少，减少IO的次数呢？一个节点存入更多的数据
但我们把整行数据都存在节点中时，会让节点的可以存储的数据量减少，我们可以使用每行数据的唯一标识放入节点再加上主键对应的地址指针。这就是B+树对B树的改造
B+树概念：
把B树中分散再各个节点的数据都放到叶子节点，非叶子节点只存储主键-地址形式的数据
B+树2个重要的特征 非叶子节点不存数据 叶子节点数据使用双向链表相连
叶子节点为有序双向链表的作用，可以帮助做范围查找
B树节点存了完整的数据，当找到数据后即可直接返回整行数据，而B+树为了能存入更多的地址，所以即使再非叶子节点找到了匹配的地址，也需要去叶子节点读取完整的数据
B树与B+树
B树的节点会存储整行数据，占用空间大存储addr少，而B+树非叶子节点只存主键-addr，能存储更多的addr 由于B+树能容纳更多的addr，所以同一个节点能指向更多的下级节点，所以相同数据量时，B+树更矮，磁盘IO少 B树的查询效率时不稳定的，最好的情况是根节点，最坏情况是叶子节点，而B+树查询是稳定的，每次查询都要到叶子节点 B+树的叶子节点是有序链表，非常便于范围查询
数据库中的一张张表，其实可以看作一颗颗B+树，索引即数据，数据即索引（只对主键索引而言）
