MariaDB 和 MySQL 5.6 之间有什么？
我们很高兴在过去的 26 个月里发布了四个生产就绪（在 MySQL 世界中更广为人知的通用版本或 GA）的主要版本。这仅仅两年多一点，却包含大量特性。同期，MySQL 发布了一个 GA 版本（MySQL 5.5），我们都热切地期待即将到来的 MySQL 5.6。
您会注意到，我们构建了MariaDB 5.1、5.2和5.3，它们基于 MySQL 5.1 代码库。MariaDB 5.3（我们迄今为止最大的 GA 版本）中包含了大量特性，其中最大的变化是在十多年来的优化器中。此外，还包含了许多基于复制的更改，例如现在著名的二进制日志的组提交。我们的知识库有MariaDB 5.3 特性摘要。
MariaDB 5.3 的工作早在 MySQL 5.5 发布 GA 版本之前就开始了。将所有这些 5.3 特性移植到 MariaDB 5.5，同时将 MariaDB 5.5 与 MySQL 5.5 合并，这是一项艰巨的任务。这导致我们的 MariaDB 5.5 作为生产就绪软件发布时出现了显著延迟。现在应该清楚的是，我们将 MariaDB 5.5 中包含了来自 5.3、5.2 和 5.1 的所有更改。我们投入时间开发新特性，并使其与当前版本的 MySQL 保持同步。
我们在四月发布了 MariaDB 5.5，并且一直致力于尽可能缩短发布周期，以跟上快速变化的发行版。考虑到这一点，许多人一直在思考从现在开始的发布周期。
我们正在开发的下一个 MariaDB 版本将如何命名？我们希望尽快在 GA 版本中发布我们的新特性，而不是等到 MySQL 5.6 达到 GA 质量。但如果我们在 MySQL 5.6 达到 GA 之前发布 GA 版本，将我们的版本称为 5.6 会非常令人困惑。此外，这次在 5.5 和 5.6 之间没有像我们在 5.1 和 5.5 之间那样可以使用的免费版本号（当时我们可以使用 5.2 和 5.3）。
我们正在考虑将其命名为 MariaDB 10.0。它将包含来自 MySQL 5.6 的稳定 GA 就绪特性（这些将反向移植），以及我们下一版本的计划中的一些内容。它将基于 MySQL 5.5 代码库。然后我们计划发布 MariaDB 10.1、MariaDB 10.2 等等。
当 MySQL 5.6 达到 GA 就绪状态时会发生什么？我们将发布 MariaDB 11.0 版本。它将包含 MariaDB 10 的所有特性，并包含来自 MySQL 5.6 代码库的特性（这些特性在之前的版本中尚未反向移植到 MariaDB）。
这是否意味着我们正在偏离与 MySQL 向后兼容的分支？当然不是。我们将具备完整的特性。我们只是在 MySQL 版本发布的空档期，类似于我们在 MariaDB 5.2 和 MariaDB 5.3 时所做的方式。敏锐的追随者会注意到，没有 MySQL 5.2 和 5.3。
本质上，这只是版本编号方案的改变。这种改变使我们能够比 MySQL 更频繁地发布版本。欢迎您在maria-discuss邮件列表中参与讨论。
不遵循 MySQL 版本号将给“通用客户端”带来巨大麻烦，包括 GUI 客户端。这些客户端会解析版本字符串来决定哪些特性应该在客户端中启用，哪些不应该。如果您发布基于 MySQL 5.5 的 MariaDB 10.0，大多数此类客户端会简单地认为它具有 5.6 的所有特性（因为 10.0 比 5.6 数字大！）。当然，这与您如何称呼它（从营销角度）无关——重要的是“SELECT VERSION();”返回什么
我建议它应该返回“5.5.x – extended with MariaDB 10.x”
当然，只要这只是一个单一例外，就可以在代码中处理（但没有针对此例外的代码的旧客户端版本会感到困惑），而且如果您一开始就这么做，我敢打赌情况只会随着时间变得更糟！
感谢您关于 SELECT VERSION(); 的宝贵反馈！我们一定会考虑这一点。
感谢您关于 SELECT VERSION(); 的宝贵反馈！我们一定会考虑这一点。
+1 同意 Peter 所说。此外还需要更多基准测试！Percona 和 Oracle 发布的测试结果表明，MariaDB 可能包含许多性能倒退，仅在某些非常有限的情况下比其他版本快。针对边缘情况进行优化很好，但如果其他领域的问题抵消了收益……
你好 Bartek！更多基准测试即将到来。您指的是 Oracle 的哪些基准测试？
抱歉，找不到 Oracle 的那些测试——一定是我想到了“Oracle 发布版本”。不过，有很多问题需要解决（列表如下）。我并不是说这些问题没有被处理，但尽管问题被指出，你们那边很少有公开的后续行动。缺乏信息很难权衡优化带来的可能收益与常规工作负载中可能出现的损失。理想情况下，应该有一套基准测试，包括针对常规工作负载和 MariaDB 特有的，每次 MariaDB 发布时都应提供其结果。
http://www.mysqlperformanceblog.com/2012/04/04/join-optimizations-in-mysql-5-6-and-mariadb-5-5/
与 MySQL 5.5 相比，冷缓存下的 Join 优化性能差
http://mysqlmaniac.com/2012/what-about-the-subqueries/
禁用子查询缓存时，子查询性能差。
http://www.mysqlperformanceblog.com/2012/02/18/mariadb-5-3-4-benchmarks/
Sysbench 性能非常差。
https://mariadb.org.cn/benchmarking-mariadb-5-3-4/
与 MySQL 5.1 相比性能差
http://www.mysqlperformanceblog.com/2012/03/21/multi-range-read-mrr-in-mysql-5-6-and-mariadb-5-5/
在内存工作负载下，多范围读取性能差
http://blog.montyprogram.com/mariadb-5-3-optimizer-benchmark/
查询 11 中的随机行为。
你好,
抱歉，但我无法理解您的观点。请允许我评论您的例子
> http://www.mysqlperformanceblog.com/2012/04/04/join-optimizations-in-mysql-5-6-and-mariadb-5-5/
> 与 MySQL 5.5 相比，冷缓存下的 Join 优化性能差
这在我这边从未重现过。DBT3 是 TPC-H。对于查询 #3，MariaDB 5.5 比任何 MySQL 版本快 2-3 倍（只需看看http://blog.montyprogram.com/mariadb-5-3-optimizer-benchmark/）
> http://mysqlmaniac.com/2012/what-about-the-subqueries/
> 禁用子查询缓存时，子查询性能差。
我读到的不是这样。在禁用子查询缓存时，MariaDB 和 MySQL 一样慢。而启用此缓存后，MariaDB 更快。那么您的观点又是什么呢？
> http://www.mysqlperformanceblog.com/2012/02/18/mariadb-5-3-4-benchmarks/
> Sysbench 性能非常差。
> http://blog.montyprogram.com/benchmarking-mariadb-5-3-4/
> 与 MySQL 5.1 相比性能差
这两篇文章必须被看作是一枚硬币的两面。Vadim 测试的是 MySQL/InnoDB 与 MariaDB/XtraDB 的对比。然后确实 MySQL 更快。当您看第二篇基准测试文章时，我们还与 MariaDB/InnoDB 和 Percona Server 进行了比较。结果表明，所有糟糕的基准测试结果都来自 XtraDB——MariaDB/InnoDB 几乎与 MySQL/InnoDB 一样好。不是 MariaDB 不够好，而是 XtraDB。
> http://www.mysqlperformanceblog.com/2012/03/21/multi-range-read-mrr-in-mysql-5-6-and-mariadb-5-5/
> 在内存工作负载下，多范围读取性能差
再次是 DBT3 查询。这次是 #10。而且在我的所有基准测试中，MariaDB 再次更快。
我还应该提到，将 MySQL 5.6 与 MariaDB 5.5 进行比较就像比较苹果和梨。MariaDB 5.5 是 GA 版本，而 MySQL 5.6 更像是一个技术演示。正如我们之前所见，InnoDB 与 XtraDB 的对比有巨大差异。MySQL 5.6 在 InnoDB 方面有许多改进——MariaDB 在与 MySQL 5.6 合并时将继承这些改进（但这不会在 MySQL 5.6 成为 GA 之前发生）。因此，我们可以肯定地期待之后 MariaDB 会有另一次性能提升。
抱歉，但此时您需要放弃自己的版本控制方式，采用 Percona 的风格。如果您想发布基于 MySQL 5.5 但比 MariaDB 5.5 更新的版本，就应该称其为 5.5-x.y。Peter 指出，任何其他方式都会与现实世界（包括那些不清楚您在做什么的用户）产生重大不兼容性。只有当您完全脱离 MySQL 基础并停止完全兼容时，更改版本号使其不与 MySQL 同步才有意义。
感谢您的意见！Peter 已在他的回复中提到了解决他担忧的方案。版本控制就像一个平衡行为，一边是 MariaDB 中的新开发，另一边是底层的 MySQL 版本。
基本上我的提议是一样的，只是没有以下文本
SELECT VERSION();
5.5.x-10.0
...如果您想将其称为版本 10。我不在乎。当然，相同的版本需要用于软件包。
+1 支持 percona 风格的版本控制！
实际上，当您发布 MariaDB 5.2 时，我曾多次向 MariaDB 邮件列表抱怨。🙂
如果您想避免 5.4，您也应该避免 5.2。有/曾经有一个 MySQL 5.2 发布版本（它作为 MySQL 6.0 继续）。MySQL 5.2 的二进制文件和代码仍然可以在 FTP 镜像上找到，例如ftp://ftp.easynet.be/mysql/Downloads/MySQL-5.2/。
哦哦.. 5.4 不相关，因为我们讨论的是 >= MySQL 5.5 的版本。抱歉，我的错误！
+1 支持这里的 percona 风格的版本控制。直接跳到 10.0 没有意义。我也可以看到 Ubuntu 风格的版本控制方式可行，但前提是您坚持 6 个月（或 x 个月）的发布周期..
如果对营销有帮助，就叫它 9000 版本吧。更重要的是版本特定语法的规划行为。例如：
mysql> select /*!60000 1+ */ 1;
+—+
| 1 |
+—+
| 1 |
+—+
1 row in set (0.00 sec)
mysql> select /*!50000 1+ */ 1;
+——-+
| 1+ 1 |
+——-+
| 2 |
+——-+
1 row in set (0.00 sec)
我也认为它应该是 Peter、Henrik 和其他人提议的“mysql version string”-“mariadb version string”方案。
那么当 MySQL 在遥远的未来或不久的将来切换到 10 时会发生什么呢？为什么不将版本号乘以 10，这样例如会有 MariaDB 56.1。当然，在遥远的未来，MySQL 最终会达到版本 56。那么 MariaDB 将是版本 560，所以那不会有问题，对吧？
Oracle 支持服务的用户没有选择，因为 Oracle 不支持 MariaDB，但除此之外，简单的成本/收益分析和对两个平台未来可能发展的考虑可能倾向于 MariaDB。