MariaDB 是 MySQL 生态系统的一部分吗？

作者：Kaj Arnö

本文翻译自：https://mariadb.org/is-mariadb-part-of-the-mysql-ecosystem/

译者注：MariaDB 由 MySQL 数据库创始人 Monty 创建。SUN 公司在 2008 年 1 月收购了 MySQL 公司，而 Oracle 公司在 2009 年 4 月 20 日宣布收购经营不善的 SUN 公司。当天，Monty 启动了 MariaDB 开源项目，希望为自己的作品 MySQL 保留长期的开源版本。为了保证项目的延续性，MariaDB 商业公司于 2010 年成立，MariaDB 开源基金会于 2012 年成立。此后，主流 Linux 发行版的 MySQL“类”数据库从 MySQL 切换至 MariaDB。

为什么 MariaDB 既是独立的数据库，又是 MySQL 的自然延续

由于 MariaDB 既是一个完全独立的数据库，又是MySQL 的一个基本兼容的扩展，因此 MySQL 用户群在未来既不依赖于甲骨文，也不依赖于 MySQL 的新分支。出于务实的原因——而这些原因在 MySQL 领域一直很重要——MariaDB 是 MySQL 生态系统的一部分。

应用程序、团队、技能、投资和用例——所有这些在 MySQL 生态系统的 MariaDB 部分仍然可行。

致忧心忡忡的 MySQL 社区成员们

本文是为 MySQL 社区中那些询问下一步计划的人而写的。

如果你是 MySQL 社区的一员，并且担心它的未来，那么有一个现实情况值得承认：你不需要创建一个平行架构或新的分支。你希望完成的工作已经由 MariaDB 公开、透明且大规模地开展了。

如果你关心 MySQL 的未来，那么实际的结论就是不要让社区进一步分裂。延续已经存在。它是开放的、有管理的，并且在不断发展。选择不是在忠诚和进步之间——而是在重复和整合之间。

让我从最近听到最多的一个问题开始说起：

“那么，到底是哪种情况呢——MariaDB 是独立的数据库，还是 MySQL 的分支？”

人们通常提出这个问题时，都期望有一个单一、明确的答案。最好是二元的答案。

坦诚的答案没那么整齐划一——但却实用得多：两者皆有。

MariaDB 是独立的产品，拥有自己的商标、开发团队、治理体系、路线图和创新能力。同时，它是有意与 MySQL 兼容的——并非偶然，也不是作为临时过渡，而是对重视连续性而非颠覆性的用户的长期承诺。

在德语中，有一个词来形容这种回答：Jein —— 既是又不是。

这不是需要解决的认知失调，而是需要理解的现实。

布鲁塞尔的担忧

MySQL 生态系统的精英不到一个月前在布鲁塞尔围绕 FOSDEM 相聚。我没有参加 FOSDEM 之前周四和周五的 MySQL 日活动，但参加了周五的晚宴。直到周一傍晚，人们一直忧心忡忡，担心甲骨文公司是否有能力和意愿进一步发展 MySQL，对 MySQL 浪费其相对于 PostgreSQL 的先发优势和技术优势感到沮丧，以及让 MySQL 延年益寿、蓬勃发展的倡议，尽管它需要生命维持系统。

但 MariaDB 不就是“正确实现的 MySQL”吗？

进入 MariaDB。或者更确切地说，我们在 15 年前就以 MariaDB 5.1 作为 MySQL 的分支进入了这个领域。从那时起，我们一直在 MySQL 之上和旁边进行开发，但现在被认为是在回答当今提出的最紧迫的问题——MySQL 的未来是什么？

我们自己宣称 MariaDB 将成为 MySQL 的未来，这几乎不会让任何人感到惊讶。但现在，社区也越来越多地表达了这一观点——在 Reddit 上，以及在布鲁塞尔的万豪会议室里。

相同的根源还是同一家族？

当人们听说 MariaDB 和 MySQL 同根同源时，就很容易认为它们属于同一个“家族”，因此发展轨迹也相似。

这个结论可以理解，但具有误导性。

MariaDB 并非作为 MySQL 的复制品出现，而是对 MySQL 给我们的启示以及甲骨文如何改变 MySQL 发展轨迹的回应。共同的根源并不意味着共同的理念。恰恰相反：MariaDB 的存在正是因为社区以惨痛的教训学到了第一次（在 MySQL AB 独立时期）行不通的东西，以及第二次（在甲骨文拥有 MySQL 期间）行不通的东西。

这个悖论是真实存在的，但并非偶然：

1. MariaDB 与 MySQL 同根同源，但与甲骨文 MySQL 遵循着截然不同的理念——开放性、治理模式和社区能动性并非附带效果，而是设计目标。
2. MySQL 是必要的学习经历 —— MariaDB 的存在是因为我们现在知道如何在第二次做时做得更好。
3. 现在，我们不是 MySQL —— 我们是 MariaDB。我们尊重 MySQL 的过去，但不受其束缚 —— 为用户提供连续性，为未来争取自由。

共同的起源并不意味着共同的命运。

希望 MySQL 8.0 能够长久存在

归根结底，许多 MySQL 用户的核心感受似乎是，只要 MySQL 有未来，他们就希望继续使用它。他们对 MySQL 8.0 或多或少感到满意——性能、高可用性、易用性——但注意它很快就要到生命周期结束的时候了。对 MySQL 8.4 和 MySQL 9.7 的性能和兼容性的信任还未建立起来。

对甲骨文交付能力的担忧

围绕甲骨文对 MySQL 管理的担忧尚未形成任何规范的表述。我听到的最确切的担忧是，甲骨文故意放走了那些有机会悉心呵护 MySQL 的核心团队。因此，将过去几年开发的重要功能（如外键）发布到社区服务器上，最多只是一次性的事情。那些本可以开发更多酷炫功能的人已经离开了。

对跟踪叉的渴望

谜题的下一步有点一厢情愿。既然甲骨文并没有真正给予 MySQL 应有的关爱，那就让“我们”，也就是 MySQL 生态系统，围绕一个能做到这一点的架构来组织吧。让我们开发一个跟踪分支！ 一个围绕核心 Oracle MySQL 构建新功能的分支。

那是白日梦。我强烈建议你阅读《蒙蒂说：分叉的概念》，这是蒙蒂关于现有分叉类型的深刻文章。简而言之：鱼与熊掌不可兼得。没有新的商标和强大的开发团队，就无法分叉 MySQL。建立新的商标和新的核心数据库开发团队非常具有挑战性：在技能、信誉、时间和资金方面都是如此。听听有过类似经历的人的话吧：MariaDB。这并不容易。

令人不快的事实：MySQL 处于维护模式

为未来做出正确的决策，要求我们了解我们当前所处的位置。对许多用户来说，如今的实际情况是，MySQL 感觉已经进入了一种维护模式。

我们面临这样一种情况：一款优秀的产品（MySQL）拥有庞大的用户基础（MySQL 生态系统）和独特的技术特性（性能、高可用性、易用性、易维护性），却因核心团队被解散，其余人员被重新分配到闭源和云开发领域，实际上已停止了开发。这是不可逆转的。对已做出的决策感到遗憾并不能让甲骨文有任何进展。

令人欣慰的事实：MySQL 在 MariaDB 中得以延续

现在来回答“MariaDB 是否属于 MySQL 生态系统”这个问题，答案是肯定的。是的，MariaDB 是围绕 MySQL 的生态系统的一部分。是的，当你升级到 MariaDB 时，使用 MySQL 的几乎所有优势都得以保留：性能、高可用性、易用性和易维护性。你的技能集是兼容的。迁移根本算不上什么大迁移。

MySQL 技能集与 MariaDB 完全兼容

稍微调侃一下我们过去对 MariaDB 的定位，即把它定位为 MySQL 的直接替代品，这在某种程度上有些不幸：所有数据库管理员和其他数据库专家所具备的 MySQL 技能，在迁移到 MariaDB 时具有很高的可复用性。

作为这种连续性的一个具体例证，让我们来看一个极端的例子：2026 年 2 月 2 日星期一，lefred（弗雷德里克·德坎普斯）是布鲁塞尔万豪酒店房间里最后一个坚守阵地、捍卫甲骨文 MySQL 堡垒的人。两周后，他重新定位自己，成为了 MariaDB 基金会的 MariaDB 社区倡导者。他立即投入工作，撰写了一篇关于 MariaDB 插件架构的技术博客。如果不是因为 MySQL 和 MariaDB 之间存在相当高的兼容性，这几乎是不可能实现的。

解决方案：MySQL 8.0 在 MariaDB 11.8+中永存

如果要求使用一个名为MySQL的产品，它与 MySQL 8.0 兼容且正在积极维护，那么将不愉快的事实与愉快的事实结合起来，就不会有令人满意的答案。如果商标要求被放弃，那么从 MariaDB 11.8 起就可以保证与 MySQL 8.0 的长期兼容性。

另一个令人愉快的事实：MariaDB 远不止是 MySQL

现在来回答关于 MariaDB 是否是 MySQL 变种这个问题的“否”答案。不，MariaDB 不只是名称不同，也不只是拥有自己强大的开发团队——这些仅仅是打造差异化产品的必要条件。它在 MySQL 的基础上已经有了十五年的创新记录。

简而言之，这带来了三项关键创新，均基于 MySQL：

1. 甲骨文兼容模式。这使得星展银行（DBS）和其他高端企业客户能够摆脱高成本的闭源甲骨文数据库解决方案。
2. MariaDB 向量。高性能 AI 功能，搭建从现实世界的关系型用户数据到大型语言模型和 AI 世界的桥梁。
3. 用户驱动创新的 15 年。从系统版本化表到安全插件，所有内容都被 MySQL 和 MariaDB 之父 Monty 在庆祝博客中巧妙总结。Monty 说：庆祝 MariaDB 成立 15 周年。

兼容 MySQL 的过去，着眼未来

将“是”和“否”融合成德语的“Jein”（“Ja”和“Nein”的混合），不仅有益，而且正是这种融合使 MariaDB 成为 MySQL 的未来。

没错，MySQL 在 MariaDB 中得以延续。升级操作再简单不过，而且人们可以探讨它是否配得上“迁移”这个概念——毕竟从 MySQL 5.7 升级到 MariaDB 10.11 肯定比从 MySQL 5.7 升级到 MySQL 8.0 要容易。

不，MariaDB 完全独立于 MySQL，并且已经如此超过十年了。它有自己的未来、自己的路线图、自己的商标和自己的开发团队。

结论：MariaDB 是独立的数据库，也是 MySQL 的自然延续

如果你担心 MySQL 的未来，结论是不要创建平行架构、新商标或另一个分支。

那些能够证明这种努力正当性的工作——治理、开放性、兼容性、长期管理——已经在公共领域大规模地在 MariaDB 中开展。

实际的选择不是在忠诚与独立之间，而是在分裂与统一之间。

我的呼吁：停止将未来框定为“MySQL 与 MariaDB 之争”。

停止将 MariaDB 视为 MySQL 社区之外的事物。

建设性的下一步是与 MariaDB 以及 MariaDB 基金会展开合作。