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 协处理器高性能编程”。）

---

　　要 mysql 迁移到 maria db
　在oracle收购了sun公司之后， mysql很不幸的落在了oracle的手中，mysql与oracle db存在竞争关系，很可能导致oracle公司影响mysql的开发与开放。mysql之父widenius在意识到oracle会对mysql做动作之前对mysql另开了一个branch：mariadb。作为一个能够完全兼容mysql的开源开放产品（向下兼容），受到了很多公司的青睐，red hat fedora ，opensuse ，维基百科，谷歌，淘宝等公司都先后把mysqldb迁移到maria db，从而更好的应对未来。
当然，未来还未来，如果mariadb的价值仅仅在未来，或许没有那么多公司愿意承担风险，进行数据库的迁移，特别是谷歌这样实力雄厚的科技公司，更不会担心技术不可控性。
　　可见，哪怕是现在，maria比之mysql也有很多的优势：
性能提升

　　2.　安全透明。（完全开源，开放，mariadb的商标属于maria基金会，以保障mariadb不会再次发生mysql这种事儿
　　3.　支持更多存储引擎。（nosql backend :cassandra ）
　　4.　mariadb galera cluster

同步复制真正的multi-master，即所有节点可以同时读写数据库。
自动的节点成员控制，失效节点自动被清除。
新节点加入数据自动复制；真正的并行复制，行级。
用户可以直接连接集群，使用感受上与mysql完全一致。
　　　　优势:

因为是多主，所以不存在slavelag(延迟)；
不存在丢失事务的情况；同时具有读和写的扩展能力；
更小的客户端延迟；
节点间数据是同步的，而master/slave模式是异步的，不同slave上的binlog可能是不同的。
　　5.　与mysql完全兼容（至少是现在）。

　　风险评估。这是最现实的问题，如果数据迁移风险过大，或者迁移之后发现maria db上各种不适，将会对产品造成极大的伤害。值得庆幸的是，从maria db的官方blog上，我们看到mysql可以无缝迁移到maria的文章，还有mysql 与maria混用的相关实例。集群方面，maria采用的 galera cluster同样适用于mysql，应该不会有接入的风险。
　 当然，还有一个因素，就是尽早迁移会尽量降低复杂度，maria db与mysql未来肯定分道扬镳，兼容性会越来越差。