前言
在诸多的管理类，办公类等系统中，树形结构展示随处可见，以“部门”或"机构"来说，接触过的同学应该都知道，最终展示到页面的效果就是层级结构的那种，下图随机列举了一个部门的树型结构展示图
设计考虑因素
1、表结构设计
稍稍有点开发和表结构设计经验的同学，设计出这样一张表，应该很容易，只需要在depart表中，添加一个pid/字段即可满足要求，参考下表：
CREATE TABLE `depart` (
`depart_id` varchar(32) NOT NULL COMMENT '部门ID',
`pid` varchar(32) NOT NULL DEFAULT '0' COMMENT '组织父ID',
`name` varchar(64) NOT NULL COMMENT '部门名称',
`description` varchar(512) DEFAULT NULL COMMENT '部门描述',
`code` varchar(64) DEFAULT NULL COMMENT '部门编码',
PRIMARY KEY (`depart_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
2、业务设计
上图是一个通用的树状结构示意图，适合大多数的业务场景，以此为例，如果“部门”不是单独的存在，与部门相关的业务主要包括下面几点：
- 部门是否单独的存在，可能与部门存在直接关联的业务，比如：部门下面可以关联用户
- 部门的效果展示，加载部门树形列表时候，是动态加载呢？还是一次性返回呢？
- 和部门增删改查相关的业务
- 替他关联部门的业务，即部门是被关联的业务对象
3、性能考虑
- 全量加载不可取，没有办法的最后考虑，层级一旦过深，数据量一旦过大，查询性能将会成为噩梦
- 动态加载效果比较好，服务端开销和压力相对全量加载小很多，但动态加载的问题也很明显，层级一旦深了，用户操作体验不佳
- 层级结构的功能，对数据导入即excel导入功能实现的编码复杂度增加
关于第一点，第二点再做几点额外的补充，全量加载和动态加载的实现都可以，在小编历经的项目或产品中都有见到，实在是要看产品的设计和客户的要求，因为全量和动态加载的不同设计也会带来与之相对结果
举例来说，全量加载的好处是，数据一次性的返回给页面，页面做了渲染之后存缓存，后续再次加载的时候速度非常快，同时，类似下面这种搜索效率就非常高，因为不需要与接口交互啊
但问题也随之而来了，部门数据不是一成不变的，增删改的操作也是常有的事情，设计成全量加载，意味着初次查询的时候，一旦数据量超大，层级非常深，假如页面还需要渲染部门下关联的用户数据时，这个对服务端的压力就非常大了，稍有经验的同学应该能大概想到这个服务端的返回数据结构了吧
下面给出初步的实现思路
function(currentDepart_id){
1、查找当前部门
DB ......
2、查找当前部门的子级部门
DB ......
3、以当前部门的子部门列表为根基进行遍历，递归查询，包装返回数据
DB ......
}
从以上的代码实现来看，数据量上去之后，预估查询将会成为性能瓶颈，而且在小编的项目开发中，做过类似的测试，3个层级，每层1000条数据（未计算部门下关联用户的数据加载），在4核16G的服务器上（CPU性能普通），完成一次全量的数据加载平均在3秒左右，这个对于B端的产品，这种设计加上这种延时，用户还能接受（1000个部门，这种数据量是比较大的了）
上面分析到，全量加载的性能瓶颈在于数据库的IO，试想，查询的时候，从顶级节点或者某个节点算起，数据量越大，层级越深，查询的次数就越多，IO的开销自然就越大
解决的办法是什么呢？实践过程中，有2个经验可以参考：
- 设计合理的缓存存储结构
- 改进表结构
关于第一点，也是大家容易想到的，但如何设计才比较合理呢？以下面的这张图为例，我们可以考虑以非叶子节点为key，而叶子节点下面的集合为value，将所有的value存入一个redis的集合中，这种考虑来源于实际业务中，用户的需求验证，即真正那些具有实际意义的部门或机构数据都分布在叶子节点上面
如此一来，编码的实现上面，也许可以改造成下面这样，
1、部门新增
functiob add(params){
1、depart入库
DB ......
2、判断当前的depart的层级，是否叶子节点（是否即将成为叶子节点）
if(叶子节点){
3、寻找上级节点ID，并查询redis中的key
4、取出上级key对应的缓存集合，加入当前新增的part_id
} else {
5、创建一个新的key，即一个新的缓存空集合，等待后续数据添加（也可以不创建）
}
}
2、删除部门
functiob delete(params){
1、depart自身的删除
DB ......
2、如果当前部门下存在子集部门，是否需要一起删除子部门（结合自身的产品业务）
DB......
获取所有的非叶子节点集合
3、假设第二步成立，那么还需要以当前部门节点创建的key，并取出key中的list集合，一起进行删掉
Redis操作
拿到第二步中的所有非叶子节点集合，组装成key，循环遍历删除key（内存型操作，性能不是问题，也可以做异步）
}
全量加载结合redis是突破性能瓶颈的关键步骤，但从上面的实现上看，从编码的复杂性上确实有所提升，而且对开发者的编码要求有一定高度，但这种实现之后，可以说很大程度上将会提升查询的性能
优化查询性能的第二种考虑，表结构的改造
不少同学有疑问，表结构的改造对于性能影响能有多大呢？说出来可能你不信，模拟数据压测的时候，不采用改造后的实现，利用 5个层级的部门，每个部门1000的数据量（我指的是每个层级的每个部门数据量都是1000，大家可以计算下数据总量），每个部门下关联了500个用户，这样的数据量的最后表现是5分钟左右
看来，数据量上去了之后，查询压力确实很大，利用改造后的设计和测试效果，最终同样的数据表现，平均在15~20秒之间，这个直接是10倍多的提升，或许在我说出答案之前，也有不少同学用过，但是没有真正体会到它的妙处
在本文开始的表结构基础上面，我们加一个path字段，这样改造后的表如下：
CREATE TABLE `depart` (
`depart_id` varchar(32) NOT NULL COMMENT '部门ID',
`pid` varchar(32) NOT NULL DEFAULT '0' COMMENT '组织父ID',
`name` varchar(64) NOT NULL COMMENT '部门名称',
`description` varchar(512) DEFAULT NULL COMMENT '部门描述',
`code` varchar(64) DEFAULT NULL COMMENT '部门编码',
PRIMARY KEY (`depart_id`),
`path` varchar(128) NOT NULL COMMENT '部门路径',
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
这个path字段意义重大，通常的表现是，从第一个层级开始，每个层级假设最多可容纳10000个部门，这样第一层的数据大概长这样， 00001 ，00002，00003 … 往上依次累加，而第二层级，假如我们在00002这个部门下新增第二层级的部门时，数据表现大概长这样， 00002/00001 , 00002/00002 , 00002/00003 …往上依次累加
那么更深的层级，我就算不举例想必大家也能自行列举出后面的结构来
这么做有什么好处呢？
我们知道,mysql是支持正则表达式函数的，还有就是like，试想，我们要想一次性查询出从某个层级开始下面的所有的层级数据时，假如没有path这个字段，会怎么做呢？很明显，就是上文所说的通过递归了
但是有了path字段之后，我们可以直接利用mysql的正则表达式函数,，仍以上面的数据为例，通过下面的这两种sql，一次性的可以将一级部门（测试）这条数据的所有子集数据全部查出来，这样一来，可以说大大减少了与数据库的交互次数
此种实现容易踩坑，或者实际操作中比较容易出问题的地方在路径规则的生成上面，通常需要提前自定义一个函数，专门用户生成path，只要确保生成的path字段数据准确无误，这种实现从优化查询的性能提升上面，是很大的突破，小编所在的开发项目中，使用的便是这种方式
function generatePath(pid){
1、pid是否为顶级
2、获取父级部门的depart
3、列举出父级部门下与当前即将新增的部门同级的所有path字段
4、取出第三步中的path最大值
5、根据第四步的path最大值生成新的path
}
另外一个比较难啃的业务是，以path字段的设计之后，做部门数据的excel导入时，这个path的处理仍然是个比较复杂的实现点，这一点留待大家思考。
以上探讨了全量加载下，从业务实现到代码设计层面的优化 ， 以及表结构设计层面优化的2个方面做了比较深入的探讨，而动态加载的实现，相对来说，可以说在上面这两种实现方案的基础上，稍作引用即可，难度更小
总结下来，这里推荐一个关于这种带有层级结构形状的业务设计上的最佳实践，
表结构上，采用path字段数据加载上，尽量使用动态加载如果部门（层级结构的业务）变动不大，可以考虑引入缓存，具体实践参考本文上面所说
到此这篇关于浅谈mysql 树形结构表设计与优化的文章就介绍到这了,更多相关mysql 树形结构表优化内容请搜索编程网以前的文章或继续浏览下面的相关文章希望大家以后多多支持编程网！
