mysql 树形结构表设计与优化

前言

在诸多的管理类，办公类等系统中，树形结构展示随处可见，以“部门”或"机构"来说，接触过的同学应该都知道，最终展示到页面的效果就是层级结构的那种，下图随机列举了一个部门的树型结构展示图

设计考虑因素

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中的key4、取出上级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、获取父级部门的depart3、列举出父级部门下与当前即将新增的部门同级的所有path字段4、取出第三步中的path最大值5、根据第四步的path最大值生成新的path}

另外一个比较难啃的业务是，以path字段的设计之后，做部门数据的excel导入时，这个path的处理仍然是个比较复杂的实现点，这一点留待大家思考。

以上探讨了全量加载下，从业务实现到代码设计层面的优化，以及表结构设计层面优化的2个方面做了比较深入的探讨，而动态加载的实现，相对来说，可以说在上面这两种实现方案的基础上，稍作引用即可，难度更小

总结下来，这里推荐一个关于这种带有层级结构形状的业务设计上的最佳实践，

表结构上，采用path字段
数据加载上，尽量使用动态加载
如果部门（层级结构的业务）变动不大，可以考虑引入缓存，具体实践参考本文上面所说

以上是本篇的全部内容，最后感谢观看！

mysql 树形结构表设计与优化相关推荐

bom树形结构表设计_K/3管理视角：树形结构下的BOM管理方式！
原标题:K/3管理视角:树形结构下的BOM管理方式! BOM(物料清单),也就是以数据格式来描述产品结构的文件,是ERP使用过程中的重要组成部分.通过BOM我们能够清晰的了解产品的结构以及所需要的物料 ...
Mysql上下级结构表设计-冗余所有上下级
背景在之前的设计中,https://blog.csdn.net/zhan107876/article/details/122160799 满足了主要需求,包含上下级数据结构,也可以查询直接上下级,但 ...
Mysql上下级结构表设计
背景希望包含上下级数据结构,比如部门,希望从指定部门查询到所有下级和所有上级的数据. 本文从设计数据库表,相关sql诠释来数据表如上,我们引入一张关系表,专门存放主表的上下级关系约定:如果没有 ...
bom树形结构表设计_BOM模块常用表结构
表名: bom.bom_bill_of_materials 说明: BOM清单父项目 BILL_SEQUENCE_ID NUMBER 清单序号(关键字) ASSEMBLY_ITEM_ID NUMBER ...
MySQL之库表设计篇：一到五范式、BC范式与反范式详解
引言 MySQL的库表设计,在很多时候我们都是率性而为,往往在前期的设计中考虑并不全面,同时对于库表结构的划分也并不明确,所以很多时候在开发过程中,代码敲着敲着会去重构某张表结构,甚至大面积重构多张表 ...
mysql 列换行表设计设计_今天来讲一下怎么利用MySql进行库表设计
今天来讲一下怎么利用MySql进行库表设计 1 引擎选择在 mysql 5.1 中,引入了新的插件式存储引擎体系结构,允许将存储引擎加载到正在运新的 mysql 服务器中.使用 mysql 插件式存 ...
mysql 树形结构_结合RBAC模型讲解权限管理系统需求及表结构创建
结合RBAC模型讲解权限管理系统需求及表结构创建在本号之前的文章中,已经为大家介绍了很多关于Spring Security的使用方法,也介绍了RBAC的基于角色权限控制模型.但是很多朋友虽然已经理解 ...
mysql树形结构的效率_MySQL存储树形数据优化技笔记
1.树形结构应用场景有时我们需要保存一些树形的数据,比如组织架构.话题讨论.知识管理.商品分类等,这些数据之间存在一种递归关系,很多开发人员想到的第一个解决方案往往是记录每个节点的父节点,例如以下的 ...
树形结构表3种设计优劣分析与分享
简介在开发中经常遇到树形结构的场景,本文将以部门表为例对比几种设计的优缺点: 问题需求背景:根据部门检索人员, 问题:选择一个顶级部门情况下,跨级展示当前部门以及子部门下的所有人员,表怎么设计更合 ...
mysql 树形结构_MySQL 树形结构数据库设计 | 剑花烟雨江南
程序设计过程中,我们常常用树形结构来表示某些数据的关联关系,如企业的部门上下级.电商平台的商品分类等等,通常而言,我们需要通过数据库来完成数据的持久化.由于关系型数据库没有一个很好的树形结构解决方案, ...

mysql 树形结构表设计与优化

前言

设计考虑因素

mysql 树形结构表设计与优化相关推荐

最新文章

热门文章