现在选择继续使用
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 数据库）