数据页内部数据行之间的关系与查找

一个数据页内包含大量数据行，数据页之间构成了双向链表关系(这样是为了方便查找)，每个数据页对应一个页目录(页目录记录了主键和数据页槽位之间的对应关系)，数据行之间构成了单向链表关系 并且是从小到大排列的。

数据量少的时候(可能所有数据加起来也就够一个数据页)，通过主键查询数据的时候，先根据页目录进行二分查找，然后去槽位里取数据即可，
如果是非主键查询数据，我们无法借助页目录来快速定位槽，只能去数据页里一个一个的遍历了(数据量多了 那就是全表扫描了，每个数据页都去查找一下，使用不到任何索引)。



数据页分裂

随着数据量越来越多，一个数据页装不下这么多数据，那肯定会需要更多的数据页来装数据，但是由上面的知识我们知道 数据页内部是有序并且单向的，并且数据页之间的数据也是有序的并且单向的，也就是说后一页的数据最小值都大于前一页数据的最小值。
那么这就有一个问题了 ，比如新增的数据主键值比较小，那是不是得重新排列？ 那就有数据的移动过程？ 移动的目标就是保住数据行之间有序，数据页之间有序。
这也就是为什么UUID不适合做主键索引的原因了，因为UUID是无序的，那么在数据量大的情况下就极易造成数据页频繁分裂，让降低mysql性能。这里一般都要求主键是增长的才不会导致频繁页分裂。这个页分裂包含这里的数据页和后面说的索引列。



基于主键实现索引：
如果没主键的话，那么需求一行一行的去扫描，效率很低，如果弄一个主键目录就好了，这个目录记录的是各个页的页号和最小主键值，这样我们在根据主键查找数据的时候可以通过二分查找 直接通过主键目录定位数据所在页，
然后再根据这个页上的页目录二分查找，就能找到数据对应的槽了，然后再去槽里取数据，效率很快

数据太多导致主键目录太多，形成B+树索引：

如果数据越来越多，那么一两个主键目录肯定是不够的，就需要更多的主键目录了。那么这些主键目录怎样排列呢？数组和链表显然效率都不够，它们之间的排列方式是树。

随着数据页分裂，索引页也分裂成树状结构了，当然 这个索引页的各个节点也是有序的，	
查找的时候从树的顶层往下查找就可以了，这个树的非叶子节点都是主键目录(也叫索引页)，叶子节点对应的是数据页。这就是mysql中的B+树。




理解聚簇索引：

每一层的索引也有双向引用关系(做这个处理的目的是在范围查询如">"查询,可以快速在当前层找到符合条件的索引页)

表里的数据就是直接放在聚簇索引里的，作为叶子节点的数据页