关于查询用户关系的效率问题

[cmwsssss]

本人菜鸟一枚，现在有一个需求是：
有一张用户表是主表 t_user
有很多用户之间的关系表，比如用户之间有没有关注的t_follow表，有没有访问的t_visit表等等，大概有十多个状态。
然后我现在作为一个用户，拉取30个用户的用户信息，然后同时要根据t_follow,t_visit等关系表里的数据获取用户相对于我的状态。

现在我的做法是先拉出30个用户，然后在service层根据每一个关系表拉对应的数据，再填进模型里面，这样处理的结果就是接口会很慢，大概接近1s才能处理完，各位大神能给个优化的方法或思路吗？

谢谢各位大佬

[这名字好厉害O]

可以多表联查，t_user作为主表，通过join on连接其余子表，并查出相应字段。

[MR_WANG0312]

上边说的用left join 然后建索引，基本上都很快

[长江水面写日记]

存redis里

[cmwsssss]

我是做的app后端，不是web，填进模型是指dao层用sql查出结果，然后service层把结果分别组装到usermodel的status里面，我再试试看是redis快一些还是join快一些，因为这些status会经常变更，放redis感觉有些奇怪，像访问次数，每一次访问都会变更，那redis里面对应的也就每次都要变，这样就感觉起不到redis本来缓存的效果

[weixin_13316459763]

受教了，我也有这样的问题

[长江水面写日记]

引用 7 楼 cmwsssss 的回复:

我是做的app后端，不是web，填进模型是指dao层用sql查出结果，然后service层把结果分别组装到usermodel的status里面，我再试试看是redis快一些还是join快一些，因为这些status会经常变更，放redis感觉有些奇怪，像访问次数，每一次访问都会变更，那redis里面对应的也就每次都要变，这样就感觉起不到redis本来缓存的效果

访问次数变了,redis里肯定要变,比操作在硬盘里的表数据要快的多,我觉得是因为你们公司表结构设计的不合理,还有对redis的api不太熟悉的问题. 访问怎么可能每次都要穿透到数据库呢?这不是开玩笑嘛?

[cmwsssss]

引用 1 楼 这名字好厉害O 的回复:

可以多表联查，t_user作为主表，通过join on连接其余子表，并查出相应字段。

谢谢您的回答，考虑过使用多表联查，user表和其他的属性表比如user_detail等等表用过join，但是实际效果反而没有多次查询以后拼装起来快，所以这个地方没有采用。而且据很多文章都说join最好不用吗？

[cmwsssss]

引用 3 楼 长江水面写日记 的回复:

存redis里

user的信息是放在redis里面的，但是连关系都放在redis里面的话这个数据量会不会太大了？而且这个关系还会经常变更，似乎有点不合适

[长江水面写日记]

我看你说填进模型里,是前后端不分离的吗?那就用ajax异步处理啊.另外redis里,以id为主键,存user的所有关注者的id,然后用原子的inc方法存访问次数一点问题都没有,redis性能很高的

[这名字好厉害O]

引用 8 楼 weixin_13316459763 的回复:

受教了，我也有这样的问题

你们数据库表有建索引吗？在需要经常查询的列上加上索引能大幅提升效率，避免全局查询，详情可以查下sql语句优化。一般来说除非你数据量特别大，要不然left join对查询速度影响不大。

[cmwsssss]

有索引的，用了连表以后速度确实有提升，原来这个接口需要1s,现在大概是0.5s，但是还有没有更好的优化方法呢，现在我的做法是一次把用户所有的关联状态查出来了，这个速度很快了，大概10ms左右，确实比原来一个个表查要快，但是这个接口一次要返回30个用户，就代表我要先把用户基本信息查出来，再一个个的去查30个用户对应的关联状态，这个种情况还有办法优化吗？