怎样优化接口返回大体量数据？

Question

需求描述：

外围平台调用接口根据手机号查询用户的歌单推荐信息，每个用户会有一千条左右的推荐信息，每条推荐信息包括了，歌曲ID、歌曲名称、版权ID、试听地址字段。

我需要关联多张表查询，每次查询时间大概4s左右，查询出来后还需要组装数据，然后才返回接口。

返回格式是json。这样的话接口返回会比较慢。

想过提前将数据放redis集群，但是后来否定了，因为用户量大概是500多万，每个用户的推荐信息大小大概200kb,存redis的话会耗费大量的内存，所以否定了。但是想不到其它给好的处理方法，请各位大神帮忙看看这样一个需求有什么好的处理建议吗？感谢！

Answer 1

感谢各位大神的积极帮助，问题还是出自sql上，这个问题但是考虑的时候只考虑到以用户为中心最终产出数据的方便性，忽略了数据中的共享性，用户偏好的歌曲数据本身就存在大量的冗余，也就是可能大家都喜欢某一首歌曲，如果以用户为中心存储数据的话，可能每个用户的数据里都包含了某一首歌曲。但是我先将歌曲信息单独提取出来存储，那么这个数据将精简到几十万，然后再利用用户偏好的歌曲id去关联到歌曲信息。通过将原来的mobile——>songInfo 改为
mobile——>songId，songId——>songInfo，这样一个关系进行解耦能达到去除冗余，提高效率的效果。

Answer 2

瓶颈出在查询很多张表需要4秒上，这里面的逻辑有可以优化的点吗？如果没有那么这4秒必须花费，其他的数据传输格式，网络通信时间再优化也无法小于4秒了。
要么在客户端在某个用户无感知的情况下发推荐请求，要么优化查询逻辑。

Answer 3

你链表查询，把你的sql贴出来，另外为什么不分开查询呢？估计你耗时在SQ

Answer 4

1.一次返回一千条？一次50条会不会快点呢？多次分页请求呢？
2.觉得直接把缓存方案否了不妥，500多w的用户，并不都是活跃用户，估算出活跃用户的量的redis可以接受不？
3

Answer 5

在【推荐信息】上添加ID属性，保存在redis，这个量应该不会大。

每个用户推荐的信息也存在redis上，但是只保存1000个【推荐信息】的ID。

这样的话就不会造成每个用户的推荐信息有200kb了。