这是一个创建于 2051 天前的主题，其中的信息可能已经有所发展或是发生改变。
现有账户表 t_user，订单表 t_order ,两张表通过 userid 关联。
t_user 内部有上下级关系 级别 LV1 LV2 LV3... LVn
需求：LV1 可以看到 lv2 级 lv2 所有下级，下下级的订单信息，其他级别以此类推;
备注：lv1 的 lv2 级别用户可能有多个
目前解决方式： 获取 lv1 得所有 lv2 级 lv2 所有下级，下下级的...用户的 userid，然后取 t_order 表中查找( select * from t_order where uid in (***,****,***))
问题：数据量小得化，系统还能扛得住，假设 lv2 级别得用户有 1W,感觉紧紧一个查询，数据库就吃不消。
请教这种情况改怎么破？
t_user 内部有上下级关系 级别 LV1 LV2 LV3... LVn
需求：LV1 可以看到 lv2 级 lv2 所有下级，下下级的订单信息，其他级别以此类推;
备注：lv1 的 lv2 级别用户可能有多个
目前解决方式： 获取 lv1 得所有 lv2 级 lv2 所有下级，下下级的...用户的 userid，然后取 t_order 表中查找( select * from t_order where uid in (***,****,***))
问题：数据量小得化，系统还能扛得住，假设 lv2 级别得用户有 1W,感觉紧紧一个查询，数据库就吃不消。
请教这种情况改怎么破？
 | 1 nicolassggsuper OP 编辑时，点击太快，发布出来了。 求指点 |
 | 2 luman 2020-02-28 09:26:08 +08:00 前段时间刚做过一个。最后实现的大概思路是，先使用闭包表建立关系方便查询下线，订单表使用两张，一张原始订单记录，一张存储父子级关系与步长。 |
 | 3 absolutely 2020-02-28 09:26:38 +08:00 无限极？ |
| 4 luman 2020-02-28 09:29:21 +08:00 |
| 5 nicolassggsuper OP @absolutely 可能是 10 级 |
 | 6 reus 2020-02-28 09:41:25 +08:00 超过三级就是传销，要进去的，小心了 |
| 7 reus 2020-02-28 09:44:14 +08:00  1 @nicolassggsuper 10 级？ 3 级都算擦边球了，之前封了一大批，10 级就是明送，如果你不是老板，赶紧跑路。 |
| 8 nicolassggsuper OP @sunjiayao 我们不涉及到佣金分红，感谢提醒。请问： 上下级步长 指的是？ 如果 LV5 购买了 1 一个订单，上级是 LV4，那么 第二张订单保重存储几条记录？ 上下级步长是几？ |
| 9 nicolassggsuper OP @reus 我们不涉及到佣金分红，谢谢 |
| 10 luman 2020-02-28 09:56:58 +08:00 @nicolassggsuper #8 就是第几级下线的意思。如果你们需要记录十级（含）下线的订单关系，那所谓的步长最大就是 10。 当 LV5 购买一个订单时。在创建原始订单后，要将其和其所有上级分别生产一条记录订单（数据量可能比较大，但没关系）。 即为： LV1 | LV5 LV2 | LV5 . . . . |
| 11 nicolassggsuper OP @sunjiayao 明白了，感谢，非常感谢！ |
 | 12 mjVtb96d2bap2u3Z 2020-02-28 10:49:02 +08:00 @sunjiayao 如果涉及到上下级关系中途变更的，怎么处理比较好？ |
 | 13 optional 2020-02-28 11:05:55 +08:00 树形结构有两种实现方式， 一种是 parent_id 方式存储， 这个可以用 cte 递归查询实现 一种是 path 前缀树方式存储， 查询直接 like prefix%就行。 前者调整灵活但是查询效率低，后者查询效率高但是灵活性少一点，实现的时候也可以两种都实现，在修改 parent_id 的时候同时保存前缀。 |
 | 14 troycode 2020-02-28 11:19:59 +08:00 存储过程来读吧 |
 | 15 DoubleShut 2020-02-28 11:23:25 +08:00 同 13 楼，两种方式都实现 |
 | 16 luckyrayyy 2020-02-28 11:32:00 +08:00 是否可以直接缓存一个全体人员关系树？到时候能直接取到所有下级子树的 id。 |
| 17 nicolassggsuper OP @luckyrayyy 人员关系树缓存不是问题，按照 @optional 的方式也可以。 但最终需要的获取具体订单的性能 |
| 18 luckyrayyy 2020-02-28 11:39:25 +08:00 @nicolassggsuper 你的问题是最后怎么读这么多订单？这不是得分页么 |
 | 19 sampeng 2020-02-28 13:13:01 +08:00 via iPhone 不要用 parentid 的方式。用二叉树实现。无限分类 |
 | 20 yikyo 2020-02-28 13:39:06 +08:00 数据库读多写少的树型结构，可用左右值模式，限制只能有一个根。 |
 | 21 HonoSV 2020-02-28 14:09:02 +08:00 mark，我现在这个项目也是做分销。13 楼提到的 parentId 和 path 方式都有用到。 |
 | 22 jayin 2020-02-28 14:16:21 +08:00 上面的做法我都想过，也实践过。最后做法是，维护一个关系表 relation 表，记录用户 A 的所有下级用户 ID+用户层级。维护这个表是复杂点，但是各种查询性能快、简单。 |
| 23 nicolassggsuper OP |
| 24 nicolassggsuper OP @jayin 你这种思路是可行的，并且效率能接受 |
| 25 HonoSV 2020-02-28 14:32:39 +08:00 @nicolassggsuper 我们只用在 user 表上，所以订单展示要联一次表，因为用户量不大，所以还没啥性能问题。。。mark 也是看看还有没有更好的方案。 |
 | 26 sun019 2020-02-28 14:41:21 +08:00 无限极分类吧 13 楼说的第一种 |
 | 27 keepsmilence 2020-02-28 14:43:24 +08:00 现在习惯设计关系表是都有 parent_id 和 parent_ids （ path ）两个字段，parent_id 记录所属上级 id，parent_ids 从所属上级记录读取它的 parent_ids 后追加上级 id，逗号分隔；如果需要修改关系，修改后从新的关系更新 parent_ids ；之后查询就像上面那样，用「 like ,XXX,%」查询出所有下级 id （注意加了前后逗号，避免通配）后再用 id 集合查出订单； |
| 28 keepsmilence 2020-02-28 14:47:47 +08:00 噢，还有，如果任意一级更新了 parent_id，除了要从他的上级继承 parent_ids 之外，还要有个触发机制更新所有下级的 parent_ids |
| 29 optional 2020-02-28 14:55:05 +08:00 @nicolassggsuper 当然是用户了，订单上有需要去 join 啊 |
 | 30 doublleft 2020-02-28 16:11:03 +08:00 在前段用点击触发下钻可以么，节省很多 |
Select Language