mysql索引的数据结构，为什么用b+树

谈到索引，大家并不陌生。索引本身是一种数据结构，存在的目的主要是为了缩短数据检索的时间，最大程度减少磁盘 IO。

任何有数据的场景几乎都有索引，比如手机通讯录、文件系统（ext4\xfs\ntfs)、数据库系统（MySQL\Oracle）。数据库系统和文件系统一般都采用 B+ 树来存储索引信息，B+ 树兼顾写和读的性能，最极端时检索复杂度为 O(logN)，其中 N 指的是节点数量，logN 表示对磁盘 IO 扫描的总次数。

MySQL 支持的索引结构有四种：B+ 树，R 树，HASH，FULLTEXT。

B 树是一种多叉的 AVL 树。B-Tree 减少了 AVL 数的高度，增加了每个节点的 KEY 数量。

B 树的特性：（m 为阶数：结点的孩子个数最大值）

1. 树中每个节点最多含有 m 个孩子节点 (m>=2)；

2. 除根节点和叶子结点外，其他节点的孩子数量 >=ceil(m / 2)；

3. 若根节点不是叶子结点，最少有两个孩子

特殊情况：没有孩子的根结点，即根结点为叶子结点，整棵树只有一个根节点；

4. 每个非叶子结点中包含有 n 个关键字信息：(n，P0，K1，P1，K2，P2，......，Kn，Pn) 其中：

Ki (i=1...n) 为关键字，且关键字按顺序升序排序 K(i-1)<Ki

Pi 为指向儿子节点的指针，且指针 P(i-1) 指向的儿子节点里所有关键字均小于 Ki，但都大于 K(i-1)

关键字的个数 n 必须满足：[ceil(m / 2)-1]<= n <= m-1

如果一个结点有 n 个关键字，那么该结点有 n+1 个分支。这 n+1 个关键字按照递增顺序排列

所有叶子结点都出现在同一层，是所有遍历的终点位置

这种情况可以通过左连接实现

可以看到左连接是以左表为基准，通过关联关系id = pid去找到对应的上级组织记录，所以空的id找不到对应的记录，返回空

有时候我们需要获取某个组织的完整路径 如

部门C/部门C_2/部门C_2_1/部门C_2_1_1

编写存储过程，生成一个临时表tmpLst，按照层级把每一条记录插入到临时表，然后每次从临时表查当前层级的组织，循环去查组织表的上级组织，直到结果ROW_COUNT = 0为止，代表当前层级下的所有组织已经是最后一级

查询到的结果，大家可以自行优化一下显示方式和查询的字段

当然还有另一种方式，从设计上解决

如新加一个唯一约束，把组织的约束定义为 ORG_001_ORG_001_002_ORG_001_003 这样的形式

当需要查询ORG_001所有的下级时，只需要查询约束 like ORG_001% 即可

当需要查询ORG_001_002所有上级时，只需要查询约束 like %ORG_001_002

不过问题在于如果组织的存在架构调整，如，ORG_001_002调整到了 ORG_002下，因为树型结构变化了，直接用like无法查询到正确数据，这个时候要考虑是否允许调整或者调整后修改对应的唯一约束