筆者明白，有些錯誤印象是因為某些無良技術服務公司，為了賺錢而誤導相關人員所致。有些問題是由於歷史原因而導致的錯誤印象，但是任何事物都是發展的，或許有些問題早已在新版本中給解決了。為此，筆者整理了一些常見的MySQL錯誤印象，希望開發人員能夠以發展的眼光來看待事物。
錯誤印象一：InnoDB存儲引擎適合寫密集型應用，MyISAM適合讀密集型應用
回答：這個問題大該在8，9年前，也就是2005年的時候在論壇是非常有爭論的話題，而上述答案算是在那個年代的一種總結。其實這個答案僅回答了堆表與索引組織表在更新時的區別，其他很多問題沒有考慮。到目前的MySQL 5.6為止，InnoDB存儲引擎已經完勝MyISAM了，看不到任何其他應用使用MyISAM的必要性。當然，MyISAM存儲引擎本身已經徹底停止開發了。
錯誤印象二：InnoDB存儲引擎存在並發問題，大並發下性能較差
回答：InnoDB的並發問題其實一直是官方改進的重點，目前已經調優的非常不錯，MySQL 5.7下只讀查詢可以輕松達到50W QPS就是最好的證明。另外，Oracle官方對於各種並發瓶頸也進行了優化，比如SSD盤並行刷新優化，重做日志優化，undo多線程purge優化等等，所以InnoDB存儲引擎本身存在的並發問題其實已經很少了。如果是上層的並發瓶頸，比如之前筆者說的電商秒殺問題(回復77可以查看)，則可以通過線程池技術來進行優化。
錯誤印象三：MySQL復制是不可靠的，經常會導致數據丟失或者復制失敗
回答：的確，在MySQL 5.6版本之前，MySQL的復制是存在一些問題的，復制可能是不可靠的。但是在2年半前發布的MySQL 5.6版本中，已經完全解決了復制可靠性問題。如果小伙伴們還出現出錯問題，基本可以定義為配置問題，有需求的可以聯系筆者來幫你調優。使用筆者的開源MySQL版本InnoSQL，可以免費獲得技術支持。
錯誤印象四：MySQL復制是邏輯復制，所以速度慢，不及Oracle這類的物理復制
回答：邏輯復制肯定慢於物理復制?不一定吧，各種綜合因素都很多吧。之前MySQL復制比較慢是因為其復制是單線程的，所以延遲問題比較嚴重。然MySQL 5.7、MariaDB 10.0已經支持並行復制功能，延遲問題基本已經解決。比如網易電商使用並行復制後，復制延遲從5個小時降低為0。
錯誤印象五：MySQL復制不能保證主從數據完全一致，不適合數據嚴格一致要求的場景
回答：上述這個錯誤觀點竟然出自淘寶的VP，筆者只能說為了推廣淘寶自己的OceanBase，已經不擇手段的來抹黑MySQL了。MySQL 5.7已提供了數據零丟失的復制方法，配置一個參數就能解決。類似的PostgreSQL、Oracle也都是通過先寫遠程日志來保障數據零丟失，這本身並不是很新的技術。而網易也已經在雲數據庫中使用該技術有近3年的時間(InnoSQL早在5.5就已經支持)，可以說是完全經過線上應用考驗的技術。只能說有些細節問題可能需要考慮，不過有問題，同樣可以咨詢筆者。
錯誤印象六：sync_binlog需設置為0或者2
回答：MySQL 5.6版本之前存在組提交失效的問題，所以需要把這個參數設置為0或者2來提高性能。但這意味著開啟了番多拉魔盒，存在很多的隱藏問題。MySQL 5.6，InnoSQL 5.5，MariaDB 5.5版本都已經解決組提交失效問題。so，sync_binlog務必設置為1
