1 讀寫速度

這存儲數(shù)據(jù)方式往往決定讀寫的速度。

• MySQL 無論數(shù)據(jù)還是索引都存放在硬盤中。到要使用的時候才交換到內存中。能夠處理遠超過內存總量的數(shù)據(jù)。

• MongoDB 的所有數(shù)據(jù)實際上是存放在硬盤的，所有要操作的數(shù)據(jù)通過 mmap 的方式映射到內存某個區(qū)域內。然后，MongoDB 就在這塊區(qū)域里面進行數(shù)據(jù)修改，避免了零碎的硬盤操作。

• redis 所有數(shù)據(jù)都是放在內存中的。但是它也支持數(shù)據(jù)持久化到硬盤中。

我們都知道磁盤讀取數(shù)據(jù)的效率遠遠低于內存。所以在一般情況下，這三者的讀寫數(shù)據(jù)的速度排序是：Redis > MongoDB > Mysql

2 是否支持事務以及復雜查詢

MySql 是關系型數(shù)據(jù)庫，支持事務操作以及 join 方式的復結構化查詢。而 MongoDB 是非關系型數(shù)據(jù)庫, 既不支持事務操作，也不支持 join 操作。Redis 同樣不支持。

因此，針對以下場景應考慮使用 MySql：
1）業(yè)務數(shù)據(jù)中有大量結構化數(shù)據(jù)，如用戶賬號、地址等。因為這些數(shù)據(jù)通常需要做結構化查詢。
2）業(yè)務存在許多事務性操作，需要保證事務的強一致性。

3 業(yè)務數(shù)據(jù)量增長速度

在一到兩年內，業(yè)務數(shù)據(jù)的增長量不在預測范圍內，優(yōu)先考慮使用 MongoDB。

因為 MongoDB 內建了sharding、很多數(shù)據(jù)分片的特性，容易水平擴展，比較好的適應大數(shù)據(jù)量增長的需求。而 MySql 在這方面表現(xiàn)要遜色些，MySql 單表數(shù)據(jù)量達到 5-10 G 時會出現(xiàn)明細的性能降級，需要做數(shù)據(jù)的水平和垂直拆分、庫的拆分完成擴展。

Redis 由于內存容量限制，不會用來存儲大量數(shù)據(jù)。一般拿它做緩存。

4 表結構是否明確

如果在業(yè)務場景中，數(shù)據(jù)庫表接口不明確，數(shù)據(jù)還在不斷增加。例如以下場景，內容管理平臺（如 BBS 論壇中帖子場景），用戶社交平臺（如貼吧中的帖子以及用戶評論），優(yōu)先考慮使用 MangDB 。

因為 MongoDB 是非結構化文檔數(shù)據(jù)庫，擴展字段很容易且不會影響原有數(shù)據(jù)。