1、讀寫速度

這存儲數據方式往往決定(ding)讀寫(xie)的速度。

Mysql 無論數據(ju)還是索引都(dou)存放(fang)在(zai)硬盤中。到(dao)要使用的時候才交換到(dao)內存中。能夠處理(li)遠(yuan)超過內存總量的數據(ju)。

MongoDB 的(de)所有(you)數(shu)據(ju)實際(ji)上是(shi)存放在硬(ying)盤(pan)的(de)，所有(you)要操(cao)作的(de)數(shu)據(ju)通過 mmap 的(de)方(fang)式映射到內存某個區(qu)域(yu)(yu)內。然(ran)后，MongoDB 就在這(zhe)塊區(qu)域(yu)(yu)里面進行(xing)數(shu)據(ju)修改，避免了零碎的(de)硬(ying)盤(pan)操(cao)作。

Redis 所有數(shu)據都是(shi)放(fang)在(zai)內存中的。但是(shi)它也支持數(shu)據持久(jiu)化到硬盤中。

我們都知道磁盤(pan)讀取(qu)數據(ju)的(de)效率遠(yuan)遠(yuan)低于內(nei)存。所(suo)以在一般情況下(xia)，這三者的(de)讀寫(xie)數據(ju)的(de)速(su)度排(pai)序(xu)是：Redis > MongoDB > Mysql

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

MySql 是(shi)(shi)關系型數(shu)據庫，支(zhi)持(chi)事務操作以(yi)及 join 方(fang)式的復結(jie)構化查(cha)詢(xun)。而 MongoDB 是(shi)(shi)非關系型數(shu)據庫, 既不支(zhi)持(chi)事務操作，也不支(zhi)持(chi) join 操作。Redis 同樣不支(zhi)持(chi)。

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

3、業務數據量增長速度

在(zai)一到兩年內，業務數據的增(zeng)長量不在(zai)預測范圍內，優先考(kao)慮使用 MongoDB。

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

Redis 由于內存容量(liang)限(xian)制，不(bu)會用來存儲(chu)大量(liang)數據(ju)。一般拿它(ta)做緩(huan)存。

4、表結構是否明確

如(ru)果在(zai)業務(wu)場景中(zhong)(zhong)，數(shu)據庫表接口不明確，數(shu)據還(huan)在(zai)不斷增加。例如(ru)以下(xia)場景，內容管理平臺(tai)（如(ru) BBS 論壇中(zhong)(zhong)帖子場景），用(yong)戶社交平臺(tai)（如(ru)貼吧中(zhong)(zhong)的帖子以及用(yong)戶評論），優先(xian)考慮(lv)使用(yong) MangDB 。

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