目前数据表设计成上图这个样子假设表名是user_fans 用户A的用户id是1 用户B的用户id是2用户A关注用户B 则插入数据时, 4个字段分别是 1 1 2 0用户B关注用户A 则插入数据时, 4个字段分别是 2 2 1 0此时他们是互粉状态 我将2条记录的status字段都由0改为1用户A查看自己的粉丝列表 SQL则是 select fans_id, status from user_fans where user_id = 1然后status字段可以用来判断用户A的粉丝和用户A的关系状态但是这样存在一个问题就是 比如用户A查看用户B的粉丝列表此时用户B的粉丝列表和用户A之间的关系就不好确定只能先把用户A所有关注的用户id都查询出来, 然后遍历用户B的粉丝列表(假设查20个人出来, 遍历20长度的数组)在foreach循环中判断20次用户B的粉丝的id是否在用户A的关注的数组中数据量小的话应该不会有性能问题但是比如用户A的关注了3000个人 那么查询出用户A关注的用户数组中就有3000个ID, 这样用户A每次查看他人的粉丝列表都会很慢, 引起性能问题, 请问有没有好的办法解决这样的问题?看网上有的文章说粉丝与关注这样的系统应该使用redis, 如果用redis, 具体怎么使用, 用什么数据类型?
1 回答
一只名叫tom的猫
TA贡献1906条经验 获得超3个赞
你的思路反了，判断b粉丝列表中用户与a的关系的时候，仅判断当前页面的用户即可，不会先把a的所有关注找出来再去判断关系的
比方说当前在b粉丝列表第一页，有20条用户，只要检查这20个用户和a的关系即可，而不是把a的所有关注找出来，再去遍历b的粉丝列表判断关系
看了问题评论中的对话，再补充一下
1、对于一个正常的用户来说，关注数是不会无限制增大的，一般正常的在十到百的级别，多的在千级别
2、一般来说，对于用户主动关注的行为，会设置一个关注上限
在1和2的前提下，用户a的关注列表量级是可控而且不大的
3、查的时候，不是把a的粉丝列表都查出来，然后再去遍历20次，而是判断这20个用户在不在a的关注列表中，这两个是不一样的
- 1 回答
- 0 关注
- 754 浏览
添加回答
举报
0/150
提交
取消