数据库对比：选择MariaDB还是MySQL？

译者 | EverSQL 翻译者 | 邪见 这首诗的目地主要就是较为 MySQL 和 MariaDB 间的主要就相似点和不同之处。他们将从操控性、可靠性和主要就机能各方面对这三个资料库进行对照，同列出在优先选择资料库时须要考量的关键事宜。谁在采用 MySQL 和 MariaDB？

MySQL 和 MariaDB 都正式发布了各别的使用者成员名单。

采用 MySQL 的有 Facebook、Github、YouTube、Twitter、PayPal、微软、Spotify、Netflix 等。

采用 MariaDB 的有 Redhat、DBS、Suse、Ubuntu、1＆1、Ingenico 等。

有一些令人激动的新机能（如询问处函数、配角掌控或公用表函数（CTE））可能将值得一提的是，但责任编辑而已为的是较为三个资料库，因此他们在这儿只探讨当中另一方专门针对提供更多的机能，以期更快地协助听众优先选择最合适自己的资料库。

让他们上看呵呵多于当中三个资料库专门针对提供更多的机能：

1. JSON 正则函数——从 5.7 版已经开始，MySQL 全力支持由 RFC 7159 表述的原生植物 JSON 正则函数，可以高效率地出访 JSON 文件格式中的统计数据。

MariaDB 没提供更多而此进一步增强机能，指出 JSON 正则函数并非 SQL 国际标准的一小部分。但为的是全力支持从 MySQL 拷贝统计数据，MariaDB 为 JSON 表述了三个别称，事实上就是三个 LONGTEXT 列。MariaDB 宣称二者间没明显的操控性差别，但他们并没提供更多基准测试统计数据来全力支持这个讲法。

更为关键的是，MySQL 和 MariaDB 都提供更多了许多 JSON 有关函数，用作更方便快捷地出访、导出和索引 JSON 统计数据。

2. 预设身份认证——在 MySQL 8.0 中，预设的身份认证应用程序是 caching_sha2_password，而并非 mysql_native_password。这一进一步增强透过采用 SHA-256 演算法提升了可靠性。

3. MySQL Shell——MySQL Shell 是 MySQL 的高级命令行客户端和代码编辑器。除了 SQL 之外，MySQL Shell 还提供更多了 JavaScript 和 Python 脚本机能。不过使用者不能采用 mysqlsh 出访 MariaDB 服务器，因为 MariaDB 不全力支持 MySQL X 协议。

4. 加密——MySQL 对重做 / 撤消日志进行了加密（可配），但不加密临时表空间或二进制日志。相反，MariaDB 全力支持二进制日志和临时表加密。

5. 密钥管理——MariaDB 提供更多开箱即用的 AWS 密钥管理应用程序。MySQL 也提供更多了许多用作密钥管理的应用程序，但它们仅在企业版中可用。

6. sys 模式——MySQL 8.0 提供更多了 sys 模式，这是一组对象，可协助资料库管理员和软件工程师更快地理解透过 Performance 模式收集的统计数据。sys 模式对象可用作优化和诊断，不过 MariaDB 没提供更多这个进一步增强机能。

7. validate_password 应用程序——validate_password 应用程序主要就用于测试密码并提升可靠性。MySQL 预设启用了这个应用程序，而 MariaDB 则不启用。

8. 超级只读—— MySQL 透过提供更多超级只读（super read-only）模式来进一步增强 read_only 机能。如果启用了 read_only，服务器只允许具有 SUPER 权限的使用者执行客户端更新。如果同时启用了 super_read_only，那么服务器将禁止具有 SUPER 权限的使用者执行客户端更新。

9. 不可见列——这个机能在 MariaDB 上可用，MySQL 不全力支持该机能。这个机能允许创建未在 SELECT * 语句中出现的列，而在进行插入时，如果它们的名字没出现在 INSERT 语句中，就不须要为这些列提供更多值。

10. 线程池——MariaDB 全力支持连接线程池，这对于短查询和 CPU 密集型的工作负载（OLTP）来说非常有用。在 MySQL 的社区版中，线程数是固定的，因而限制了这种灵活性。MySQL 计划在企业版中增加线程池机能。

近年来，出现了很多关于 MySQL 和 MariaDB 引擎操控性的基准测试。他们不指出“MySQL 或 MariaDB 哪个更快”这个问题会有一个最终的答案，它在很大程度上取决于具体的采用场景、查询、使用者和连接数量等因素。

不过，如果你确实想知道，下面列出了他们发现的许多最新的基准测试结果。请注意，这些测试都是在一组特定的资料库 + 引擎（例如 MySQL+InnoDB）组合上进行的，因此得出的结论只与特定的组合有关。

MySQL 8.0（InnoDB）和 MariaDB 10.3.7（MyRocks）基准测试对照：

Benchmarking InnoDB and MyRocks Performance using Sysbench

MariaDB 10.1 和 MySQL 5.7 在商用硬件上的操控性对照：

MariaDB 10.1 and MySQL 5.7 performance on commodity hardware

MySQL 8.0 和 MariaDB 10.3.5 操控性对照及 UTF8 的影响：

http://dimitrik.free.fr/blog/archives/2018/04/mysql-performance-80-and-utf8-impact.html

三个资料库都提供更多了将统计数据从三个服务器拷贝到另三个服务器的机能。它们的主要就区别是大多数 MariaDB 版允许你从 MySQL 拷贝统计数据，这意味着你可以轻松地将 MySQL 迁移到 MariaDB。但反过来却没那么容易，因为大多数 MySQL 版都不允许从 MariaDB 拷贝统计数据。

此外，更为关键的是，MySQL GTID 不同于 MariaDB GTID，所以将统计数据从 MySQL 拷贝到 MariaDB 后，GTID 统计数据将相应地做出调整。

以下是这三个资料库在拷贝配置各方面的许多差别：

MySQL 的预设二进制日志格式是基于行的，而在 MariaDB 中，默认的二进制日志格式是混合式的。

log_bin_compress——这个配置决定了是否可以压缩二进制日志。这个进一步增强机能是 MariaDB 独有的，因此 MySQL 不全力支持。

MariaDB 的文件格式中列出了 MySQL 和 MariaDB 间的数百个不兼容问题。因此，他们无法透过简单的方案在这三个资料库间进行迁移。

大多数资料库管理员都希望 MariaDB 而已作为 MySQL 的一个 branch，这样就可以轻松地在二者间进行迁移。但从最新正式发布的几个版上看，这种想法是不现实的。MariaDB 事实上是 MySQL 的三个 fork，这意味着在它们间进行迁移须要考量很多东西。

MariaDB 比 MySQL 全力支持更多的存储引擎类型。但话说回来，资料库可以全力支持多少个存储引擎并不关键，关键的是哪个资料库可以全力支持适合你需求的存储引擎。

MariaDB 全力支持的存储引擎包括：XtraDB、InnoDB、MariaDB ColumnStore、Aria、Archive、Blackhole、Cassandra Storage Engine、Connect、CSV、FederatedX、Memory、Merge、Mroonga、MyISAM、MyRocks、QQGraph、Sequence Storage Engine、SphinxSE、Spider、TokuDB。

MySQL 全力支持的存储引擎包括：InnoDB、MyISAM、Memory、CSV、Archive、Blackhole、Merge、Federated、Example。

当你在某些 Linux 发行版上安装 MySQL 时，最后可能将安装的是 MariaDB，因为它是很多（并非全部）Linux 发行版的预设设置。

Red Hat Enterprise/CentOS/Fedora/Debian 发行版预设会安装 MariaDB，而其他发行版（如 Ubuntu）预设安装 MySQL。

MariaDB 可作为运行在 Amazon Web Services（AWS）、微软 Azure 和 Rackspace Cloud 上的服务。

MySQL 在上面提到的三个平台上也是可用的，同时还可以作为托管服务在谷歌云服务平台上运行。

因此，如果你正在采用谷歌云平台，并希望云提供更多商为你管理服务，那么可以考量采用 MySQL，除非你希望自己安装和管理 MariaDB 实例。

MariaDB 采用了 GPL v2 许可，而 MySQL 提供更多了三个许可选项——GPL v2（用作社区版）和企业许可。

MySQL 的三个许可间的主要就区别在于可用的机能和全力支持服务。使用者可以采用 MariaDB 的所有机能，但对于 MySQL 来说并非如此。MySQL 的社区版不包含线程池等机能，而这些机能会对统计数据库和查询操控性产生重大影响。

通常，MariaDB 的正式发布频率比 MySQL 更频繁。太高的正式发布频率既有利也有弊。从好的各方面来说，使用者可以更及时地收到机能和错误修复。从不好的各方面来说，为的是让 MariaDB 保持最新的状态，须要更多的工作量。

MySQL 的全力支持团队（包括 MySQL 开发人员和全力支持工程师）为客户提供更多全天候服务。甲骨文提供更多了多种全力支持选项，包括扩展全力支持、持续全力支持和高级全力支持，具体取决于客户的要求。MariaDB 全力支持团队的全力支持工程师包括了 MariaDB 和 MySQL 资料库专家（因为很多机能最初是由 MySQL 团队开发的），他们为生产系统提供更多全天候的企业级全力支持。

MySQL 的开发者主要就是甲骨文的 MySQL 团队，而 MariaDB 开发透过公开投票和邮件列表探讨的方式进行。此外，任何人都可以向 MariaDB 提交补丁，MariaDB 开发团队会考量将这些补丁添加到主代码库中。因此，从某种程度上说，MariaDB 是由社区开发的，而 MySQL 主要就由甲骨文开发。

好吧，他们无法为你做出决定。他们能做的就是有针对性地问你许多问题，然后你自己做出决定：

你是否分别基于这三个资料库对你的产品操控性做过测试？哪三个表现更快，为什么？

你是否打算采用当中三个资料库专门针对提供更多的机能？

你是否打算采用当中三个资料库专门针对提供更多的资料库引擎？

能够对资料库的开发过程产生影响对你来说有多关键？能够参与下三个机能变更投票对你来说有多关键？

你是要为企业版付费却是采用社区版？社区版的机能是否能够满足你的需求？

你的操作系统是否预设全力支持你所选的资料库？要部署它需不须要很多工作量？

你采用的是哪个云提供更多商？他们是否提供更多托管服务，当中包括你优先选择的资料库？

你是否计划将来从一种资料库类型迁移到另一种资料库类型？如果是这样，你是否考量过兼容性和拷贝各方面的问题？

如果你能回答好这些问题，可能将就很清楚哪个资料库更适合你。

https://www.eversql.com/mariadb-vs-mysql/