很多問題並非只有一個解決方案的，這意味著你既可以使用這種技術，也可以使用那種技術。學習目的隨便怎樣都可以，但是真實生產環境中強烈建議簡化你的複雜度，用最簡單的，你自己最熟悉的方式解決問題。思考一下是否真的有必要使用2個資料庫來解決同一個問題。

我在想如果把歌曲查詢部分做成從MongoDB裡查詢，速度是不是會快一些？

可能會，也可能不會。取決於你有多少資料量，使用MongoDB的資料模型設計是否合理，以及…你打算投入多少硬體資源在上面。 NoSQL更專注於水平擴展，就是說在資料量不斷增加的情況下，仍然能夠保持查詢速度在一定的水平上。個人的經驗，如果有個幾千萬，上億的數據，MongoDB可能才會真正發揮優勢來。在資料到達這個量級之前，如果只是從速度上考慮我認為沒有很大的必要引入額外一個資料庫。它帶來的收益跟對你造成的複雜度對比起來，只能說性價比不高。

以後對歌曲資訊的增刪寫的時候，同時要跟MongoDB同步一下，是這樣吧？

資料同步的問題取決於你對「一致性」的要求有多高。在強一致的情況下，這就是一個分散式事務，恐怕對效能不是一件好事，違背了你想加快速度的初衷。如果是考慮最終一致性，可以看各種MySQL到MongoDB的ETL工具，例如Pentaho。當然自己透過程式碼實現也是可能的，只是考慮好各種容錯問題並不是一件容易的事情。

首先，你要知道清楚一點，MongoDB 是 NoSQL 的一種具體實現，不同於 Redis，其儲存的資料結構是文件式的。

其次，查詢速度是很難在產品與產品或引擎與引擎的差異中做武斷地決定，需要根據實際使用情況進行權衡，不僅如此，存儲什麼信息，如何存儲也是要做些分析的（如果只是練習實踐的話過程上可以簡單點）。

之前也是只學了 MySQL，因為儲存的某些資料的結構的不確定性或複雜性，要單用 MySQL 來儲存就要使用許多表格和設定外鍵，所以也學習了 MongoDB 來解決需求。

我做的是一個圖書的練習實踐，某種角度和歌曲有些相似。例如，圖書的作者可能不只一個，如果用MySQL，簡單的方法則會使用分隔符號來實作一個欄位內儲存多個作者，後期做查詢會有一定的問題（判斷條件的複雜甚至效能），而一首歌曲的演唱者也可能不只一個。

我的實作是 MySQL + MongoDB，當然只用 MongoDB 也是可以實現的，不過認為具體需求要對應分析。我的綜合練習實踐還在繼續，可以隨時交流，以上提供的一種想法。

Elasticsearch 做查詢更快，而且還不影響mysql效能

我猜你可能需要根據歌詞來尋找歌曲等功能。上面提到的Elasticsearch就很好，還有一個選擇sphinx，做全文檢索也很不錯。