很多问题并非只有一个解决方案的，这意味着你既可以用这种技术，也可以用那种技术。学习目的随便怎样都可以，但是真实生产环境中强烈建议简化你的复杂度，用最简单的，你自己最熟悉的方式解决问题。思考一下是否真的有必要使用2个数据库来解决同一个问题。

我在想如果把歌曲查询部分做成从MongoDB里查询，速度是不是会快一些？

可能会，也可能不会。取决于你有多少数据量，使用MongoDB的数据模型设计是否合理，以及……你打算投入多少硬件资源在上面。NoSQL更专注于水平扩展，就是说在数据量不断增加的情况下，仍然能够保持查询速度在一定的水平上。个人的经验，如果有个几千万，上亿的数据，MongoDB可能才会真正发挥出优势来。在数据到达这个量级之前，如果仅仅是从速度上考虑我认为没有很大的必要引入额外一个数据库。它带来的收益跟对你造成的复杂度对比起来，只能说性价比不高。

以后对歌曲信息的增删写的时候，同时要跟MongoDB同步一下，是这样吧？

数据同步的问题取决于你对“一致性”的要求有多高。强一致的情况下，这就是一个分布式事务，恐怕对性能不是一件好事，违背了你想加快速度的初衷。如果是考虑最终一致性，可以看一下各种MySQL到MongoDB的ETL工具，比如Pentaho。当然自己通过代码实现也是可能的，只是考虑好各种容错问题并不是一件容易的事情。

首先，你要知道清楚一点，MongoDB 是 NoSQL 的一种具体实现，不同于 Redis，其存储的数据结构是文档式的。

其次，查询速度是很难在产品与产品或引擎与引擎的差异中做武断地决定，需要根据实际使用情况进行权衡，不仅如此，存储什么信息，如何存储也是要做些分析的（如果只是练习实践的话过程上可以简单点）。

之前也是只学了 MySQL，因为存储的某些数据的结构的不确定性或复杂性，要单用 MySQL 来存储就要使用许多表和设置外键，所以也学习了 MongoDB 来解决需求。

我做的是一个图书的练习实践，某种角度和歌曲有些相似。比如，图书的作者可能不止一个，如果用 MySQL，简单的方法则会使用分隔符来实现一个字段内存储多个作者，后期做查询会有一定的问题（判断条件的复杂甚至性能），而一首歌曲的演唱者也可能不止一个。

我的实践是 MySQL + MongoDB，当然只用 MongoDB 也是可以实现的，不过认为具体需求应该对应分析。我的综合练习实践还在继续，可以随时交流，以上提供的一种思路。

Elasticsearch 做查询更快，而且还不影响mysql性能

我猜你可能需要根据歌词查找歌曲等功能。上面提到的Elasticsearch就很好，还有一个选择sphinx，做全文检索也很不错。