先明确要查什么
- 查某人的直接下级和全部下级。
- 查某人的所有上级（用于向上分佣）。
- 统计团队总人数和总业绩。
- 判断层级深度，防止无限层级。
三种常见方案
- 邻接表：只存 parent_id，结构简单，写入快。缺点是查全部下级要递归，层级一多就慢。
- 路径枚举：在字段里存 “1/4/9/23” 这样的完整路径，用
LIKE '1/4/%'查下级，查询快。缺点是路径变长后维护麻烦，移动节点成本高。 - 闭包表：用一张独立的关系表存所有祖先后代组合及距离，查询最灵活。缺点是存储空间大，写入时要维护多行记录。
实用建议
如果层级固定为两级——这也是合规要求下最常见的做法——直接用邻接表就够了，直接下级一次查询就能拿到，团队业绩再按 ID 列表聚合统计，性能和复杂度都最好。不要为了“以后可能要多级”提前上闭包表，那是典型的过度设计。
如果确实需要多级，推荐邻接表 + 闭包表组合：邻接表负责写入，闭包表负责查询，用异步任务维护闭包表的一致性。
性能优化的几个点
- 给 parent_id、distributor_id 建索引，这是最基本的。
- 团队人数和业绩用冗余字段或缓存定时刷新，不要在列表页实时聚合。
- 排行榜走独立的统计表，按日/周/月预聚合。
- 关系链变更写日志，便于出问题时回溯和修复。