需求描述：
外圍平台調用接口根據手機號查詢用戶的歌單推薦信息，每個用戶會有一千條左右的推薦信息，每條推薦信息包括了，歌曲ID、歌曲名稱、版權ID、試聽位址欄位。
我需要關聯多張表查詢，每次查詢時間大概4s左右，查詢出來後還需要組裝數據，然後才回傳介面。
回傳格式是json。這樣的話介面回傳會比較慢。
想過提前將資料放redis集群，但是後來否定了，因為用戶量大概是500多萬，每個用戶的推薦資訊大小大概200kb,存redis的話會耗費大量的內存，所以否定了。但想不到其它給好的處理方法，請各位大神幫忙看看這樣一個需求有什麼好的處理建議嗎？感謝！
瓶頸出在查詢很多張表需要4秒上，這裡面的邏輯有可以最佳化的點嗎？如果沒有那麼這4秒必須花費，其他的資料傳輸格式，網路通訊時間再優化也無法小於4秒了。
要么在客戶端在某個用戶無感知的情況下發送推薦請求，要么優化查詢邏輯。
你鍊錶查詢，把你的sql貼出來，另外為什麼不分開查詢呢？估計你耗時在SQ
1.一次返回一千條？一次50條會不會快點呢？多次分頁請求呢？
2.覺得直接把快取方案否了不妥，500多w的用戶，並不都是活躍用戶，估算出活躍用戶的量的redis可以接受不？
3
在【建議資訊】上加入ID屬性，保存在redis，這個量應該不會大。
每個使用者推薦的資訊也存在redis上，但是只保存1000個【推薦資訊】的ID。
這樣的話就不會造成每個用戶的推薦資訊有200kb了。