MySQL与MariaDB哪个更优秀？

也许你对MySQL数据库新秀MariaDB有所耳闻，作为MySQL的又一分支，MariaDB诞生于甲骨文收购Sun公司之后。MariaDB拥有诸多值得认真体味的优秀特性，这不仅是由于MariaDB项目由MySQL最初创始人Monty Widenius所创建，更因为它与MySQL始终保持着紧密联系。

　　先从相关技术社区所能提供的支持与调试积极性入手，考虑利用MariaDB替代MySQL的可行性。举例来说，如果要付费签订一套技术支持协议，并且把甲骨文方案作为理想的支持交付机制，那么MySQL无疑是最合理的选择。然而，如果能把高高在上的MySQL集群CGE(即运营商级版本)的姿态放低一些，那么甲骨文提供的社区版本显然更为合适。

　　如何做出具体取舍要看各企业技术团队的实际情况以及他们对开源文化的熟悉程度。如果他们更喜欢从甲骨文的咨询服务中心获取支持信息以及官方解答，那么MySQL将成为理想的选择。

　　与MySQL相近的使用感受

　　对于那些打算尽早摆脱甲骨文控制的MySQL用户来说，兼容性无疑是需要关注的首要问题。这也是MariaDB向下兼容特性如此重要的关键所在。向下兼容意味着什么?

　　尽管两款软件包的名称有所区别，但检查其资源库时，一定会发现二者之间存在着千丝万缕的联系与高度一致的相似之处。命令行工具的二进制名称，例如mysqladmin、mysqldump、mysql shell以及后台程序都保持着名称上的统一。更进一步，二者的数据文件彼此之间也完全兼容。MariaDB能够直接与现有MySQL实例中的数据文件及表定义顺利协作。

　　持续不断的改进步伐

　　向下兼容的可贵之处在于不需要对应用程序做出任何形式或程度上的改动。利用MariaDB取代MySQL之后，大家能够立即享受由此带来的性能提升。来自Facebook、Twitter、谷歌以及Percona等媒体平台的社区支持将抢先一步入驻MariaDB，而后才逐步在MySQL中铺开。

　　MariaDB还通过数据检索信息模式给用户带来更令人满意的处理手段，其中包括微秒支持。如果大家正在使用TIME或者DATETIME数据类型，则可以为其指定特殊精度，例如TIME(4)，括号中的数字代表小数点后显示多少位。MariaDB最高支持到小数点后六位——也就是0.000001秒或者称之为1微秒。这已经是小得不能再小的时间单位了。而对于那些没有特别指定精度的用例，MariaDB会默认忽略小数点后的余数以简化读取难度。

　　你们一定有过在MySQL中执行运行时间超长的ALTER TABLE，一直等到满腔怒火的经历。MariaDB会为这类操作提供一套命令行进程指示器，这样大家就可以预先估计运行所需要的时间。这确实是一项令人拍手叫好的创新。

　　查询执行对于面向Web的应用程序来说往往算是一项重大挑战。MySQL查询执行背后的实际大脑其实是查询优化器，MariaDB在这方面也做出了一系列显著改进，包括更好的子查询优化效果、更快的执行速度、更高的执行效率以及更具一致性的连接、导出表以及视图等。另外，MariaDB为用户提供额外的控制选择，用于设定优化器如何做出决定、如何显示更多内部处理流程以及如何通过服务器参数完成配置工作。

　　MariaDB还提供一系列经过合并的内核强化机制，移除了对性能影响极大的互斥器。所谓互斥器，是一种在内核中连续访问资源的锁定机制。如果资源目前正处于占用状态，进程就必须保持等待直到资源再次可用。MySQL内核中的现有互斥器始终在现代硬件当中也会造成非常严重的拖慢现象。将其取消帮助MariaDB顺利与如今愈发常见的大型SMP设备相对接。

　　最后，如果大家希望向基于单元的复制机制转移但却受制于单元复制日志中的SQL声明问题，MariaDB也拿出了很好的解决方案。

　　基于单元的复制机制并非始终可读，因为用户一直在发送原始数据块，也就是数据在发送之前与之后的“镜像”而非实际执行的SQL声明。数据块被交付至从数据库当中并直接写入文件，而不再由SQL进行重复执行。由于这个原因，SQL声明无法成为MySQL日志内容的一部分。

　　而在MariaDB当中，SQL声明被记录在专门针对单元复制流程的库日志里，其处理方式与基于声明的复制完全相同。这部分SQL声明能够有效帮助管理人员进行故障排查并在特定情况下实现时间点恢复目标。MariaDB的此项改进堪称雪中送炭。

　　进一步挑战极限

　　对于那些希望进一步挑战极限的使用者来说，MariaDB所具备的功能足以打破固有MySQL功能的束缚。

　　初学者可以在两套高性能存储引擎当中做出选择：Aria与XtraDB。尽管二者都不具备对现有MySQL部署的向下兼容能力，但我们仍然可以通过一条简单的ALTER命令在这些引擎中重新建立表。

　　即将迎接的是一种名为Galera的全新集群化技术。这种技术与NDB Cluster及其它知名方案完全不同。Galera允许主动-主动多体更新，这一点在NDB Cluster中由于JOIN的局限而无法完成。现在大家可能真正对云服务器进行规模化写入，更令人欣喜的是，我们甚至能够使用并行及同步复制功能。

　　想要获得NoSQL般的理想速度?HandlerSocket插件是个不错的选择，它可以在不经过优化器的情况下直接访问存储引擎，从而一举将速度提升到原先的十倍以上。大家现在还可以利用MariaDB中的动态列机制获取大量JSON格式的返回数据——这同样是MySQL所无法企及的。

　　MariaDB中还包含另一套全新存储引擎，这就是Cassandra SE。它允许用户向一套Cassandra数据存储体系内写入或者读取数据。SQL与NoSQL之间的融合终于不再令人头痛。

　　想要合并来自不同主数据库内的数据?多源复制功能正是满足大家需求的最佳方案。假设我们的源数据被保存在多个实例当中，MariaDB能够将它们同时引导到同一个下游实例当中——这样的效果在MySQL中仍然无法实现。

　　如果前面提到的这些新特性还不足以吸引你，MariaDB还拥有一套杀手锏——它其实是一个完全遵循GPL许可的MySQL版本。所有相关插件及功能组件都是开源方案，这相当于帮助使用者在安全性及调试识别透明度等各个方面都享受到了开源带来的便利。MySQL则适用于GPL或者由甲骨文提供的商业许可，这就导致一部分组件开源、另一部分闭源。

　　在苹果和桔子之间做出选择

　　如果大家正着手评估各类MySQL替代发行版，肯定需要认真权衡它们各自的优势与弱项。

　　就以Percona为例，它足以成为甲骨文MySQL社区版本的另一种替代方案。Percona往往在引入新功能方面表现得更为保守，这相当于在稳定性方面做出一丁点提升、但却在获得最新最优秀的功能方面畏首畏尾。Percona相对于MySQL也算得上是很大的进步，不过也许仍然无法像MariaDB那样为我们带来业界顶尖的解决方案。

　　Drizzle也是MySQL替代者大家庭中的另一位成员，只不过它的特色在于通过重新编写适应云部署环境。它确实属于开源项目没错，但却并没能提供面向MySQL的向下兼容能力。大家需要舍弃原有数据并重新载入新数据，甚至对应用程序做出调整，只有这样它才能顺畅地运行下去。

　　虽然MariaDB在普及程度上与Percona尚存在一定差距，但它的人气增长速度却不容小觑。举例来说，红帽公司就已经在自己的企业发行版中利用MariaDB取代MySQL;谷歌公司最近也针对MariaDB项目组织了一次工程师投票。在欣欣向荣的MySQL替代方案领域，MariaDB正以日益壮大之势稳步迈向王者宝座。