前言

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

设计考虑因素

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

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

1、量大不使用push

push一个json对象，对象子节点是一个有1000条数据的数组，无法加载，页面卡住了

将
treeData.push(JSON.parse(result));

改为

treeData[0] = JSON.parse(result);

加载成功

2、自适应数量级，div 高度和宽度有边界

优化树形拓扑结构，目前可以显示1w个设备，1w个就已经看不清了，这个受浏览器限制，经测试只能控制在屏幕宽度的30倍

 //主要就是这里
			    var container = document.getElementById('main');
			    var allNode = 0;
			    var nodes = myChart._chartsViews[0]._data._graphicEls;
			    console.log("节点数：",nodes.length)
			    for (let i = 0, count = nodes.length; i < count; i++) {
			        let node = nodes[i];
			        if (node === undefined)
			            continue;
			        allNode++;
			    }
			    var width = window.innerWidth;
			    var height = window.innerHeight;
			    //计算最大宽度
			    var currentWidth = 40 * allNode;
			    if(currentWidth > width*30){
			    	newWidth = width*30;
			    }else{
			    	newWidth = Math.max(currentWidth, width);
			    }
			    //console.log('----myChart._chartsViews[0]._data._graphicEls:',myChart._chartsViews[0]._data._graphicEls);
			    //console.log('----myChart._chartsViews[0]._data.tree._nodes:',getArrayLayer(treeData,'children',1));
			    //计算最大高度
			    var currentHeihgt = ( 200 * (getArrayLayer(treeData,'children',1)-1) +100);
			    if(currentHeihgt>height*6){
			    	newHeight = height*6;
			    }else{
			    	//newHeight = Math.max(currentHeihgt, height);
			    	newHeight = currentHeihgt;
			    }
			    container.style.width = newWidth + 'px';
			    container.style.height = newHeight + 'px';
			    //option.series[0].height = currentHeihgt + 'px';
			    myChart.resize();
			
			    //setAppScale(newWidth,newHeight);

在有限的经验下，主要讨论以下两部分内容

1.对树形数据结构的查询,且层级较少，采用添加分级字段的方式优化
2.针对前端使用ztree ，list直接返回结果集，存在授权问题的查询，采用添加层次码的方案

1.针对需要树结构的查询

• 在有限的多级目录情况下，可以添加分级字段，（1级目录，2级目录，3级目录），

• 1.在这个基础上假设只有三级目录，那么我们可以直接分3次查询，此时得到了3个关于1、 2、 3层级对应的list；
• 2.上一步的操作，使我们极大的改善了数据库查询的效率，只需要3次查询即可拿到所有的数据，但同样，需要解决拼树的问题
• 3.对树的拼接，在目前大部分服务器使用多核的情况下，推荐使用java8 Stream操作对原始list进行加工。

基于以上假设，单条数据如下，即正常查询list中数据泛型为Regions

		@Data
		public class Regions {
		    private Integer objectId;//id
		    private String regionName;//区域名称
		    private String regionCode;//区域编码
		    private Integer level;//区域级别
		    private String parentCode;//上级区域编号
		}

返回到页面的对象

@Data
	public class TreeNode {
	    private String regionName;
	    private String regionCode;
	    private String parentCode;
	    List<TreeNode> children;
	}

算法写法

import javax.annotation.Resource;
import java.util.List;
import java.util.stream.Collectors;

import static java.util.stream.Collectors.toList;

@Service
public class RegionServiceImpl implements RegionService {
    @Resource
    private RegionsMapper regionsMapper;

    @Override
    public List<TreeNode> getRegionTree() {
    	//根据层级关系查询了3次
        List<Regions> level1 = regionsMapper.getListByLevel(1);
        List<Regions> level2 = regionsMapper.getListByLevel(2);
        List<Regions> level3 = regionsMapper.getListByLevel(3);
        //先将最末级转为TreeNode 的形式
        List<TreeNode> node3 = level3.stream().map(l3 -> {
            TreeNode treeNode = new TreeNode();
            treeNode.setRegionCode(l3.getRegionCode());
            treeNode.setRegionName(l3.getRegionName());
            treeNode.setParentCode(l3.getParentCode());
            //没有下级children 不做处理
            return treeNode;
        }).collect(toList());

        //对二级目录进行抽象
        List<TreeNode> node2 = level2.stream().map(a -> {
            TreeNode treeNode = new TreeNode();
            treeNode.setRegionName(a.getRegionName());
            treeNode.setRegionCode(a.getRegionCode());
            treeNode.setParentCode(a.getParentCode());
            treeNode.setChildren(node3.stream().filter(l3 -> l3.getParentCode().equals(a.getRegionCode())).collect(toList()));
            return treeNode;
        }).collect(toList());
        //对一级目录继续抽象并返回
        List<TreeNode> node1 = level1.stream().map(a -> {
            TreeNode treeNode = new TreeNode();
            treeNode.setRegionName(a.getRegionName());
            treeNode.setRegionCode(a.getRegionCode());
            treeNode.setParentCode(a.getParentCode());
            treeNode.setChildren(node2.stream().filter(l2 -> l2.getParentCode().equals(a.getRegionCode())).collect(toList()));
            return treeNode;
        }).collect(toList());
        return node1;
    }
}

1000条数据，耗时1s多一点，这里作者连的是远程数据库加上网速也不是很乐观，若网络连接畅通，还会快一些。

备注 ：若层级较多时，可以进一步简化（抽象），以for循环的形式读取每个层级的数据，然后以同样以for循环的形式对数据进行从低到高的封装，一个方法做循环层级读取数据，另一个方法做对多个层级进行 树的推导

2.针对zTree授权树的查询优化

• 前言：

• 前端使用zTree插件时，可以进一步简化后端的查询，也不存在树的结构化返回，实际上，如果没有权限的管理，我们只需要拿到所有的数据，并对数据字段进行取别名，使其符合zTree的规范即可。

• 当目录层级存在权限时，比如子目录存在权限，但父目录并没有授权，但在前端界面中，我们同样需要加载父级目录显示给用户，以维持整个目录的结构。

• 思考

  理论上，我们从上往下进行递归，每验证一个目录需要验证 它 及它的子目录 是否存在权限，如果存在权限，那么就将这个目录存放到list中，并继续递归它的下级目录
  弊端 ：当数据量较大时，其需要不断查询下级目录，并不断做验证权限的查询，验证 本级及下级是否存在权限 理论上也需要做递归，这样就导致了大量的查询操作，使效率极大的被限制。

• 解决方案

  加入层次码（同样是不可重复的）字段，即 比如上级菜单的层次码为 xxx ，那么下级菜单的层次码 必定为xxxyyy 或xxxzzz，并且它的多层子目录的层次码必定为xxx开头。
  基于以上的假设，我们的思路如下：

  • 1.查询到所有的已授权目录的层次码,并标识为这样的一个List 集合：List<Authority> authList Authority 主要字段为 ccm（层次码）

  • 2.查询所有的目录，即不管是否存在授权都进行查询 ，存放于：List<Menu> menus ，Menu的主要字段是业务字段，及ccm 字段，注意menus 是可以直接返回到前端的一个list，我们现在要做的只是筛选授权的数据，并返回即可

  • 3.使用java 8 Stream 方法，根据层次码进行筛选，代码如下：

    public List<Menus> getAuthroityMenus(){
        List<Menus> menus = new ArrayList<>();//假设这里查询了数据库，获得了所有的目录
        List<Authority> authList = new ArrayList<>();//假设这里查询了数据库，得到了所有授权的目录
        
       return menus.stream().filter(a->{
            //a,表示每一个menu对象
            //同样的，下方的b 对应每一个Authority对象
            //遍历授权目录，如果 授权目录的ccm   以此刻的Menu.ccm 开头，则表示这个menu是已授权的上级，
            if (authList.stream().filter(b->b.getCcm().startsWith(a.getCcm())).count()>0){
                return true;
            }
            return false;
        }).collect(Collectors.toList());
        
    }

java8 的写法有不了解的可以搜下相关资料，博主自己也写过一些java 8相关的内容，这里就不做具体的细节介绍了。
有疑问或有其他更好的方法，也希望大家在评论区积极发言！