分销商表有三个字段：id、level、inviter_id。level表示分销商等级，由小到大0、1、2、3。inviter_id表示当前分销商的邀请人，也是另一个分销商id，存在一个邀请人递归关系。

不断递归邀请人，找到第一个level比当前分销商高的就是当前分销商的上级。

之前想过分销商表再加一个parent_id，记录上级，后来讨论，当邀请链路比较长，又因为企业微信也做了一个修改分销商等级的审批，一旦分销商等级有调整，可能会有大量分销商的parent_id修改，而其他有需求依赖分销商等级，如果计算有问题，会有一些影响。所以分销商下级的需求暂时不做。

但分销商上级可以做，只在需要的地方临时计算获取，不在表里加parent_id。同样因为邀请链路可能比较长，而且是递归计算，一直调sql，性能会比较差，决定拿到数据后在内存中递归。因为计算的是邀请链路上的邀请人，所以只需从数据库取这部分数据，其他数据取了也是浪费内存，所以新增一个root_id，表示同一个链路，level=3表示公司，2是公司邀请的分销商，所以root_id对应的level都是2的id。这里参考了多级评论列表。

剩下的就是已有数据root_id数据订正；内存里递归计算，达到条件后退出循环