筆者明白，有些錯誤印象是因為某些無良技術(shù)服務(wù)公司，為了賺錢而誤導(dǎo)相關(guān)人員所致。有些問題是由于歷史原因而導(dǎo)致的錯誤印象，但是任何事物都是發(fā)展的，或許有些問題早已在新版本中給解決了。為此，筆者整理了一些常見的MySQL錯誤印象，希望開發(fā)人員能夠以發(fā)展的眼光來看待事物。

[[138343]]

錯誤印象一：InnoDB存儲引擎適合寫密集型應(yīng)用，MyISAM適合讀密集型應(yīng)用

回答：這個問題大該在8，9年前，也就是2005年的時候在論壇是非常有爭論的話題，而上述答案算是在那個年代的一種總結(jié)。其實這個答案僅回答了堆表與索引組織表在更新時的區(qū)別，其他很多問題沒有考慮。到目前的MySQL 5.6為止，InnoDB存儲引擎已經(jīng)完勝MyISAM了，看不到任何其他應(yīng)用使用MyISAM的必要性。當然，MyISAM存儲引擎本身已經(jīng)徹底停止開發(fā)了。

錯誤印象二：InnoDB存儲引擎存在并發(fā)問題，大并發(fā)下性能較差

回答：InnoDB的并發(fā)問題其實一直是官方改進的重點，目前已經(jīng)調(diào)優(yōu)的非常不錯，MySQL 5.7下只讀查詢可以輕松達到50W QPS就是***的證明。另外，Oracle官方對于各種并發(fā)瓶頸也進行了優(yōu)化，比如SSD盤并行刷新優(yōu)化，重做日志優(yōu)化，undo多線程purge優(yōu)化等等，所以InnoDB存儲引擎本身存在的并發(fā)問題其實已經(jīng)很少了。如果是上層的并發(fā)瓶頸，比如之前筆者說的電商秒殺問題(回復(fù)77可以查看)，則可以通過線程池技術(shù)來進行優(yōu)化。

錯誤印象三：MySQL復(fù)制是不可靠的，經(jīng)常會導(dǎo)致數(shù)據(jù)丟失或者復(fù)制失敗

回答：的確，在MySQL 5.6版本之前，MySQL的復(fù)制是存在一些問題的，復(fù)制可能是不可靠的。但是在2年半前發(fā)布的MySQL 5.6版本中，已經(jīng)完全解決了復(fù)制可靠性問題。如果小伙伴們還出現(xiàn)出錯問題，基本可以定義為配置問題，有需求的可以聯(lián)系筆者來幫你調(diào)優(yōu)。使用筆者的開源MySQL版本InnoSQL，可以免費獲得技術(shù)支持。

錯誤印象四：MySQL復(fù)制是邏輯復(fù)制，所以速度慢，不及Oracle這類的物理復(fù)制

回答：邏輯復(fù)制肯定慢于物理復(fù)制?不一定吧，各種綜合因素都很多吧。之前MySQL復(fù)制比較慢是因為其復(fù)制是單線程的，所以延遲問題比較嚴重。然MySQL 5.7、MariaDB 10.0已經(jīng)支持并行復(fù)制功能，延遲問題基本已經(jīng)解決。比如網(wǎng)易電商使用并行復(fù)制后，復(fù)制延遲從5個小時降低為0。

錯誤印象五：MySQL復(fù)制不能保證主從數(shù)據(jù)完全一致，不適合數(shù)據(jù)嚴格一致要求的場景

回答：上述這個錯誤觀點竟然出自淘寶的VP，筆者只能說為了推廣淘寶自己的OceanBase，已經(jīng)不擇手段的來抹黑MySQL了。MySQL 5.7已提供了數(shù)據(jù)零丟失的復(fù)制方法，配置一個參數(shù)就能解決。類似的PostgreSQL、Oracle也都是通過先寫遠程日志來保障數(shù)據(jù)零丟失，這本身并不是很新的技術(shù)。而網(wǎng)易也已經(jīng)在云數(shù)據(jù)庫中使用該技術(shù)有近3年的時間(InnoSQL早在5.5就已經(jīng)支持)，可以說是完全經(jīng)過線上應(yīng)用考驗的技術(shù)。只能說有些細節(jié)問題可能需要考慮，不過有問題，同樣可以咨詢筆者。

錯誤印象六：sync_binlog需設(shè)置為0或者2

回答：MySQL 5.6版本之前存在組提交失效的問題，所以需要把這個參數(shù)設(shè)置為0或者2來提高性能。但這意味著開啟了番多拉魔盒，存在很多的隱藏問題。MySQL 5.6，InnoSQL 5.5，MariaDB 5.5版本都已經(jīng)解決組提交失效問題。so，sync_binlog務(wù)必設(shè)置為1