現在選擇繼續使用
MySQL或拋棄它切換到MariaDB有足夠的理由。
現在把目光移到benchmark上面來，它其實也是由MariaDB團隊開發的，并加了一下額外的說明。這篇博客提到了一個有趣的地方：把MYSQL5.6的線程數一直增加到16，性能都很好，但是超過了16的話，盡管性能也有提升一點點，但比較發現，遠不如其他版本(包括MairaDB-5.5.28a和MairaDB-10.0.1;參考
文章頂部的
性能測試圖）。這在單核計算機里
面試圖達到多核多線程的效果的并行程序時，都會有此類的通病。如果算法設計得當，隨著CPU核心數的增加，性能也會跟著提升。當然問題是，你必須在并行程序中處理好2個方面：(1)跨多核的多線程問題(2)矢量化。這也是當前面向多核編程的兩個方向，你編寫的必須能很好的控制這兩個方面。
如果沒有正確的編寫代碼將會得到一個共同的結果，即在用8到16個線程的開始你就想看到好的結果，但在這些線程運行之后你不會看到你期望的結果。你將會看到這個問題，這意味這可能是算法問題。(這也不是超線程或是硬件線程造成的)這就是我們在這里看到MySQL 基準的問題。對于我來說，這就是MySQL規模化產生問題的跡象，這也是令人擔心的原因之一。MariaDB在同樣的基準中也有一些小問題，但是比MySQL要輕微的多，只能說是勉強吧；我推測這個問題在并行計算中可能不會出現。
我也不知道在測試中怎樣才能很好的根據不同機器指定不同的編譯器來與之匹配。當你為Intel編譯代碼時，你需要為目標機器編譯生成合適的SIMD代碼；如果不匹配，你將不會得到你所期望執行的矢量代碼。為了能正確處理，你需要在代碼中插入正確的編譯指示代碼，然后要寫下正確的矢量算法，最后在選擇合適的編譯器。我知道這樣看起來很愚笨，但我看過一個發行產品用錯誤的編譯器所造成的結果是你無法想象的。好歹，很明顯，MySQL代碼在多核和矢量化中的優化沒有MariaDB好。
(我真正想看到的是，MySQL或MariaDB的一個分支為Intel Xeon Phi處理器核心做一個特別的編譯，使代碼轉移到61 核心協處理器，并且有人能嘗試加速所有244個線程。可惜我沒有接觸過這樣的機器。同樣的，如果你想
學習更多關于向量化和并行方式編寫代碼方面的知識，檢索最近Intel公司 James Jeffers 與 James Reinders寫的文章“Intel Xeon Phi 協處理器高性能編程”。）
很明顯，MariaDB的新特性并不是都這么好——你可能需要連接 Cassandra 來獲取一些數據，但是我很懷疑你會使用 MySQL 去做這件事情。關于這個平臺上提供的其他引擎也有類似的爭議。MariaDB的性能看起來在多核環境下表現不錯，但是我強烈懷疑其實通過調優，MySQL 也可以做到。
所以你還應該轉移到 MariaDB 嗎？
首先，考慮潛在的風險（高層管理者都喜歡聽風險和利益）。如果你遷移到 MariaDB，你可能會使用特定于 MariaDB 的特性（但目前似乎還不可能），然后發現很難再用很小的資源切換回 MySQL 。但是我想說的是，這個并不真的是一個風險，下面從更大的范圍里討論一些問題。
考慮一下關于
Oracle 以及 Oracle 對 MySQL 授權的問題。免費以及開源的 MySQL 要與 Oracle 極具競爭力的專有軟件競爭。那么，Oracle 會做什么事情阻止 MySQL 的開發呢？（一些人可能會說，這樣的事情已經發生了）
那么，MySQL 和 MariaDB 的兼容性如何呢？MariaDB 團隊正盡力去保持對 MySQL 的全面兼容，他們繼續向源碼中提交 bug 修復。但那些新特性（以及版本方案）表明，盡管盡了最大的努力，這兩個平臺還是會繼續分裂。
如果 Oracle 向 MySQL 添加 MariaDB 不采納的新特性，這些特性明顯不會對你可用。如果你正在使用 MySQL 不具備的 MariaDB 特性，你將不能輕易地切換到 MySQL 。 MariaDB 表示這樣的情況很可能存在一段時間，然而你也不能說相同的情況不會在 MySQL 中出現。就是說，即使 MariaDB 的新特性并不那么有用，但是（在我看來）已經有足夠的理由從 MySQL 遷移到 MariaDB 了。
（在結束這篇文章前說一件事：即在 blogosphere 的作者提出過的一個關鍵問題——服務協議。如果在你的公司總經理瘋狂到向 Oracle 購買了服務協議來幫助你開發管理 MySQL
數據庫，那么你可能愿意停留在MySQL 以避免因為違反協議而造成的財務和法律上的問題。但除此以外，我看不到什么理由繼續使用 MySQL 數據庫）