MariaDB 10.0 和 MySQL 5.6 有何不同

首先， 我要着重详述下为什么我们没有把MySQL 5.6 直接拿过来作为二次开发的基础，去做一个产品，可以呗称为 MariaDB 5.6. 这个原因的细节我们直接都没有和众人分享。

1. MySQL5.6 的代码库的文件结构已经被改动了。比如单个代码文件已经被分成多个，又或者是某些代码已经被重新归类到了不同的文件内。所以要把MariaDB 去配合现在这个文件结构一定是一个非常消耗时间的过程。而其实我确实不是很明白MySQL为什么要改动现有的文件结构。

2. MairaDB 5.5 已经有大量的代码不同于MySQL 5.5 的版本，而且也有很多的新的特征被整合到MariaDB 5.5 中，而这些特征知道 5.6 版本 才出现在MySQL中。所以我们在比较同样功能的MySQL 和MariaDB的版本，同时在完成设计和QA方面的审核后，一个很明显的结论是MariaDB会是一个更好的产品。在大多数情况下，在选择 MariaDB的时候，人们会更多的考虑到功能方面的偏好。

3. 所以MySQL的新代码，至少是修改bug的代码以后都没有必要进行相应的测试了。我们试想一下，当有这样一个功能要加入到一段代码中，而这个功能原本就是来源于这段代码的情况下，测试将是一个异常重要的过程来保证这个功能的正常运行。

和上文中提到的第二点和第三点一样，Stewart Smith在Percona写到关于Mysql最后安全补丁的回归测试和QA如何测试使用MariaDB工程，以及保存在Percona服务器用作回归测试的测试用例的重要性。参考： wrote yesterday about the latest security fix in MySQL introducing a regression

MariaDB不仅仅是Mysql的一个替代品。它的主要目的是创新和提高Mysql的技术，Mysql5.6不是一个合适的创新基础平台，所以我们就做了下面的事情：

1.由于我们引入了一些新功能（像  multi-source replication 多源复制, Cassandra integration , engine independent statistics 独立统计系统等），所以我们需要搞个新版本。通常当你引入新功能时，你需要新建个版本。

2.下个版本称作“MariaDB5.6”是不准确的，因为他不是基于Mysql5.6，取而代之，我们决定版本号调为10.0

3.MariaDB引入Mysql5.6作为一种替代方案的话，需要提升很多功能，我们已经迈出了第一步，正朝着合并或者重建Mysql5.6的功能方向发展。

首先，mariadb 10.0是一个主要数据库版本，比如组合后的innodb与组合后性能架构，和一个新的全局执行事务id。夏日里，mariadb 10，有可能被当做GA开放式数据库。(注释)

通过阶梯式的方法，我们的最终目的是聚合或者重新实现mysql5.6的所有功能特色。重新实现的所有功能特色都将同它们的mysql版本兼容。到此为 止，maria 10将全面兼容mysql5.6版本。除了顶部框架之外，其中含有众多附加的mariadb数据库的唯一的功能。

重 新实现功能的决定很简单。如果从我们或者用户的角度来看，MySQL 5.6缺乏该功能，那么我们就重新实现它。重新实现的决定并不是因为“我想这样做”，或者受“非自主发明综合征”的影响。每个问题都是经过认真而广泛的讨 论的。你可以加入邮件列表来参与这些讨论，并且让我们听到你的声音，邮件列表是  https://launchpad.net/~maria-developers 网站上的  maria-developers@lists.launchpad.net  。

我们是不是有其他的选择。答案是 Yes。我们本可以把最新版本的MySQL 5.6 拿过来作为MariaDB 5.6 的基础，然后在其之上进行修修补补。但是，我们需要意识到的是：MariaDB 不是一个附加的补丁程序。虽然MairaDB 实在MySQL的基础上建立起来的，但是我们有很多的工程师正在努力工作，他们的功劳是不可低估的。不得不提的是，我们全职的MariaDB 的工程师和QA人员一直在努力MySQL 技术可以更好地为MairaDB服务。

当然，还有另外一条路可以走，就是不再依赖于MySQL，并且不再兼容MySQL，如此，我们将称为一个独立的个体。但是我们不太采取这样的方案。因为我们和众多的MariaDB的用户都收益于MySQL的功能，也很想MariaDB也同样可以有这些特征。