現在選擇繼續使用MySQL或拋棄它切換到MariaDB有足夠的理由。
MariaDB 博客上的性能測試。
MariaDB是MySQL源代碼的一個分支，在意識到Oracle會對MySQL許可做什麼後分離了出來MySQL先後被Sun、Oracle收購）。這些擔憂是有依據的，我會在本文的後面講到。除了作為一個Mysql的“向下替代品”，MariaDB包括的一些新特性使它優於MySQL。
在介紹這些特性前，我想先談談MariaDB的版本編號模式。首先，MariaDB版本與Mysql版本相匹配——比如MariaDB 5.1，與MySQL 5.1使用相同的代碼。由於更新和修復是針對MySQL源碼樹的，這樣的話MariaDB可以采納這些補丁理論上，MariaDB每月都與MySQL源 碼合並）。但是如果新的獨特特性定期添加的話，我想代碼校驗肯定會是一個惡夢。
MariaDB團隊應該也意識到這一點，他們已經開始制定新的編號方案。最新的MariaDB版本目前仍處於alpha狀態）是Maria 10.0，後面跟著一個小數：
mysql -P 3406 -u root -p
Enter password: ********
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 1
Server version: 10.0.2-MariaDB mariadb.org binary distribution
Copyright (c) 2000, 2013, Oracle, Monty Program Ab and others.
Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the current input statement.
MariaDB [(none)]> select version();
+—————-+
| version() |
+—————-+
| 10.0.2-MariaDB |
+—————-+
1 row in set (0.01 sec)
MariaDB [(none)]>
MariaDB再三甚至有些散漫地解釋為什麼他們這樣做——盡管這樣讓開發者感到不適，但它就是這樣。如果依舊完全兼容Mysql的話他們不能繼續添加新特性。
至於新特征？讓我們看一下其中的幾個。
Cassandra引擎
MariaDB的一個獨特特性是它的連接到Cassandra後端的引擎。引擎本身只是一個加入到Cassandra服務器中單獨運行中介 Cassandra是一個NoSQL類型的鍵-值存儲，由Facebook創建後來成為了Apache的項目；它可用於集群且沒有單點故障，它同樣不是 完全ACID的）。通常，如果你使用Cassandra引擎的話你就無法獲得與InnoDB或extradb相近的速度或性能。
但是你可以通過MySQL訪問數據，通過允許selects、inserts、updates、deletes甚至拓展的join就像使用SQL感覺一樣，但MariaDB團隊表示Cassandra引擎不適合大量數據的分析類查詢。
所以這個功能可能有用如果你……，呃，讓我們接著看……
如果你在寫一個需要訪問Cassandra數據應用軟件，那麼你最好直接使用Cassandra的原生API而不是通過MySQL。如果你的注意力在 MySQL命令行，且需要抓一些數據，這種情況Cassandra引擎可以派上用場——但如果你打算這樣做的話，你可能只想嘗試下Cassandra的命 令行界面。
所以我真的不知道哪種是適用情況，但這並沒有阻止一些人在博客上抒發對此功能的興奮之情。
OQGraph引擎
我不會介紹這個特性的全部，因為它跟Cassandra想法相同：這個引擎是圖計算引擎的開放查詢接口。這對一些特定的應用可能有用，盡管表面上看將圖形結構映射到SQL格式有些古怪。
MariaDB的一個重要的增強力量是使用xtradb作為InnoDB的向下替代。而且xtradb增加了現代軟件所需要的可擴展能力——這是核心不同 點。Oracle聲稱MySQL現在的拓展性比以前好，可能的確如此，但引擎還是那個引擎。如果引擎不能真正具備拓展性，那麼MySQL也同樣不具備。
原子寫
選擇關系型數據庫而不是NoSQL的主要原因是前者對ACID的完全支持。簡單的說，如果有失敗，你不想丟失數據。盡管故障可能並不經常在我們的開發用機 上發生，但在很多的IT中心卻很常見。目前，默認的InnoDB/XtraDB引擎采用雙緩沖的方法來寫入數據以確保崩潰時數據能寫入成功。然而，當使用 高速的SSD設備時打個比方），雙緩存對性能有負面影響——會減小SSD在訪問速度方面的優勢。解決辦法是什麼呢？現在你可以關掉雙緩沖打開所謂的原子 寫。先在你磁盤上驗證再應用到生產環境。
同樣是一個有趣的功能，但還不是那個讓你轉用MariaDB拋棄MySQL的特性。
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 數據庫）
譯文鏈接：http://www.oschina.net/translate/mariadb-vs-mysql-a-comparison
