这是一个创建于 2794 天前的主题，其中的信息可能已经有所发展或是发生改变。
各位 V 友好，我现在遇到一个问题，我先简单描述下，这个函数的作用是传入用户 id ，通过用户 id 去查找 user 表中的"shares_tree"字段，也就是 A 找 B ， B 找 C ，依次循环下去，如果找到的用户少的话查询效率还可以，但是用户数较多的情况下，查询速度会变得异常缓慢，我知道问题是出在在循环内部调用函数，但目前我没有更好的方法优化，还望各位 V 友能够指点一二。
 |
1
Septembers 2017-03-15 09:05:56 +08:00 via iPhone
async + cache?
|
 |
2
yangqi 2017-03-15 09:07:33 +08:00
这个是数据库设计的问题，你这个做字符模糊查询肯定没法优化。只能改表结构
|
 |
3
phpdever OP @yangqi 在代码上无法优化了吗？因为 shares_tree 这个字段存放时是：“-|51|5150|1799|-”这样的。
|
|
4
yangqi 2017-03-15 09:14:48 +08:00
|
 |
5
Immortal 2017-03-15 09:26:55 +08:00  6
|
 |
6
sheep3 2017-03-15 09:29:38 +08:00 1
1. 小心循环依赖导致无限递归，最好加一个栈深度值判断一下。
2. 要不用 redis ，存 userid->user_tree_kids[] |
 |
8
jianzhiyao020 2017-03-15 09:37:48 +08:00 2
首先，
多对多的多次查询肯定是坑， 你这个需求，应该是这样子的， 分销系统， 一个用户有一个上级， 可以有多个下级， 那么我们可以这样处理， 一个字段存 tree ， 一级分销 /二级分销 /三级分销 /四级分销 /， 该 tree 字段可以建立索引， 查询本级的子节点可以用， tree like 我的 tree+'%' (伪代码) 因为 like 在前缀确认的情况下， 是可以使用索引的， 还需要一个字段，存当前层级，标注当前层级 0,1,2,3,4,5,6,7,8,9 ， 查询的时候，比自己大的就是后面的人， 这种方法，理论上可以实现无限分销。 |
 |
10
dapeng 2017-03-15 09:46:34 +08:00 1
#8 楼靠谱，感觉用 redis 的并不是能很好的解决这个问题，一是数据递增变化大，二是当数据量达到一定量级时这 redis 内存得设置多大；
最优方法还是数据库设计这块，冗余字段， 用空间换时间 |
 |
11
EchoUtopia 2017-03-15 09:48:41 +08:00
使用图数据库，或者你查询出来的时候，自己构建一个有向图放在内存里，我目前有个需求跟你类似，是这样打算的
|
|
12
Immortal 2017-03-15 10:06:15 +08:00
@jianzhiyao020 其实这样设计有点不灵活 查询起来基本没问题 但是修改起来问题很大 要更新索引 更新层级 尤其是遇到那种"升级"上的时候 更为繁琐 比如从四级->二级 连带的所有下级用户 和 层级 和 下级用户的层级 索引等等 全部要更新一次 如果层级深 这个估计也不会快
|
|
13
jianzhiyao020 2017-03-15 10:10:55 +08:00
@Immortal
分销系统的话， 这种层级维护的可能基本为 0 ， 主要是看需求， 如果说类似文件变动， 肯定是多对多， 但是， 多对多也产生了一个回溯上级的问题， 特别是分销系统，需要给上级分发奖励， 所以我觉得该类问题，应该是提需求， 而不是提技术难点。 如有疏漏， 请再次提出。 感谢。 |
 |
14
AbrahamGreyson 2017-03-15 10:26:26 +08:00 via iPhone 1
用嵌套集合模型重构数据库。
|
 |
15
whahuzhihao 2017-03-15 10:35:49 +08:00
为何不用 mongoDB ？
|
 |
16
hjxx 2017-03-15 10:39:18 +08:00 1
用左右值的方式 见 5 楼的链接
|
 |
17
dangyuluo 2017-03-15 10:52:23 +08:00
|
|
19
dapeng 2017-03-15 11:04:43 +08:00
#5 楼链接的中的方法受教了，提到的这种 mysql 结构设计思维 nice !
|
|
20
Immortal 2017-03-15 11:43:24 +08:00
@dangyuluo 应该也适用的 这个左右值如果从属关系变更 新的左右值是可以计算的 如果说层级很深的情况下 相对而言也要多次递归查询之后才能得出新值 但是一般是 读 远大于 写,是可以接受的,具体怎么计算可以研究下,之前做过,三两句话讲不清楚,是个挺有意思的问题
|
 |
21
fuxkcsdn 2017-03-15 12:32:46 +08:00 via iPhone 1
5 楼的左右值方法受教了，得去把数据结构书籍再翻出来细读了
对于真无限级别的场景，这方法真不错 对于有限（或假无限）级别的场景， 8 楼的方法更合适 |
 |
22
lucifer4he 2017-03-15 14:50:52 +08:00 1
你需要 PG 递归查询。
|
 |
23
TJT 2017-03-15 15:10:41 +08:00
之前也做过类似的需求，这是测试代码。把所有 source_id = x 的都取出来，就可以根据 refer_id 重建整棵树了。
https://ws1.sinaimg.cn/large/a95d59d7gy1fdnjiw4d39j20d804tdg6 |
|
24
TJT 2017-03-15 15:11:06 +08:00
|
|
26
TJT 2017-03-15 15:11:52 +08:00
|
 |
28
fhefh 2017-03-15 16:19:25 +08:00
先 mark ~~~
|
 |
29
none110 2017-03-15 17:28:32 +08:00 via iPhone
mark 备看
|
 |
30
eamon666 2017-03-15 19:05:16 +08:00
要是以前的话我会用 8 楼的办法来搞，现在可能更趋向于 MONGODB
|
 |
31
Time2 2017-03-15 22:03:59 +08:00
5L 的这个方案， 把数据结构中的树 的关系，联想到 数据库设计，厉害啊！
|
Select Language