甲骨文杀死了MySQL

2024-06-23 15:06

大约15年前，Oracle收购了Sun公司^[1]，从而也拥有了MySQL，互联网上关于Oracle何时会“扼杀MySQL”的讨论^[2]此起彼伏。

当时流传着各种理论：从彻底扼杀 MySQL 以减少对 Oracle 专有数据库的竞争，到干掉 MySQL 开源项目，只留下 “MySQL企业版” 作为唯一选择。

这些谣言的传播对 MariaDB，PostgreSQL 以及其他小众竞争者来说都是好生意，因此这些谣言在当时传播得非常广泛。

然而实际上，Oracle 最终把 MySQL 管理得还不错。MySQL 团队基本都保留下来了，由 MySQL 老司机 Tomas Ulin 掌舵。

MySQL 也变得更稳定、更安全。许多技术债务也解决了，许多现代开发者想要的功能也有了，例如 JSON支持和高级 SQL 标准功能的支持。

虽然有 “MySQL企业版”^[3]，它实际上关注的是开发者不太在乎的企业需求：如可插拔认证、审计、防火墙等。虽然也有专有的 GUI 图形界面、监控与备份工具（例如 MySQL 企业监控），但同样有许多开源和商业软件竞争者，因此并没有产生特别大的供应商锁定效应。

在这段时间里，我也常为 Oracle 辩护，因为许多人都觉得 MySQL 会遭受虐待，就因为 —— 它是Oracle。

我认为在那段期间，Oracle 一致遵守了这个众所周知的开源成功的黄金定律：“转换永远不应该妨碍采用。”

注：“Conversion should never compromise Adoption”
这句话指在开发或改进开源软件时，转换或升级过程中的任何变动都不应妨碍现有用户的使用习惯或新用户的加入。

然而近些年来，随着 Oracle 推出了 “MySQL Heatwave”（一种 MySQL 云数据库服务），事情开始起变化了。

MySQL Heatwave 引入了许多 MySQL 社区版或企业版中没有的功能，例如加速分析查询与机器学习。

在“分析查询”上，MySQL 的问题相当严重，到现在甚至都不支持并行查询。市场上新出来的 CPU 核数越来越多，都到几百个了，但单核性能并没有显著增长，而这严重制约了 MySQL 的分析性能提升 —— 不仅仅是分析应用的查询受限，像日常应用里简单的 GROUP BY 查询也会受影响。（备注：MySQL 8 对 DDL 有一些并行支持^[4]，但查询没有这种支持）

这么搞的原因，是不是希望用户能够有更多理由去买 MySQL Heatwave？但或者，人们其实也可以直接选择用分析能力更强的 PostgreSQL 和 ClickHouse。

另一个开源 MySQL 极为拉垮的领域是 向量检索。其他主流开源数据库都已经添加了向量检索功能，MariaDB 也正在努力实现这个功能，但就目前而言，MySQL 生态里只有云上限定的 MySQL Heatwave^[5] 才有这个功能，这实在在是令人遗憾。

然后是最奇怪的决策 —— Javascript 支持是一个只在企业版中提供的功能，我认为 MySQL 应该竭尽所能地去赢得 Javascript 开发者的心，而现在很多 JS 开发者都更倾向于更简单的 MongoDB 了。

我认为上述举措都违背了前面提到的开源黄金法则 —— 因为它们显然限制了 MySQL 的采用 —— 不论是这些“XX限定”的特定功能，还是对 MySQL 未来政策变化的担忧。

如果这还不够，MySQL 的性能也出现了严重下降，似乎是因为多年来对性能工程部门的忽视^[6]。

与MySQL 5.6 相比，单线程简单工作负载上的性能出现了大幅下滑。你可能会说增加功能难免影响性能，但 MariaDB 的性能退化要轻微得多，而 PostgreSQL 甚至能在 新增功能的同时显著提升性能^[7]。

显然，我无法窥视甲骨文管理团队的讨论，也不能说这到底是蠢还是坏，但过去几年的这些产品决策，显然不利于MySQL的普及。

特别是在同一时间，PostgreSQL 在引领用户心智上大步向前，在 DB-Engines 排名上大幅缩小了与 MySQL 的热度差距，而根据 StackOverflow开发者调查^[8] ，甚至已经超过 MySQL 成为最流行的数据库了。

无论如何，除非甲骨文转变其关注点，顾及现代开发者对关系数据库的需求，否则 MySQL 将坐以待毙 —— 无论是被 Oracle 的行为杀死，还是被 Oracle 的不作为杀死。

原文：Percona Blog，作者 Peter Zaitsev。Percona 是 MySQL 生态的重要贡献者，开发了知名的PT系列工具，MySQL备份工具，监控工具与发行版。
译者：冯若航，网名 Vonng，Pigsty 作者，PostgreSQL 专家与布道师。数据库老司机，云计算泥石流。

参考阅读

MySQL性能越来越差，Sakila将何去何从？^[9]

MySQL 的正确性为何如此垃垮？^[10]

Is Oracle Finally Killing MySQL?^[11]

Can Oracle Save MySQL?^[12]

Sakila, Where Are You Going?^[13]

Postgres vs MySQL: the impact of CPU overhead on performance^[14]

Perf regressions in MySQL from 5.6.21 to 8.0.36 using sysbench and a small server^[15]

References

[1] Oracle收购了Sun公司:
https://www.oracle.com/corporate/pressrelease/oracle-buys-sun-042009.html
[2] 关于Oracle摧毁MySQL讨论:
https://www.quora.com/Did-Oracle-buy-MySQL-in-order-to-kill-it
[3] “MySQL企业版”:
https://www.mysql.com/products/enterprise/
[4] 并行支持:
https://dev.mysql.com/blog-archive/mysql80-innodb-parallel-threads-ddl/
[5] MySQL Heatwave:
https://blogs.oracle.com/mysql/post/introducing-vector-store-and-generative-ai-in-mysql-heatwave
[6] MYSQL 多年来对性能工程部门的忽视:
https://smalldatum.blogspot.com/2024/04/sysbench-on-small-server-mariadb-and.html
[7] PG在新增功能的同时显著提升性能:
https://smalldatum.blogspot.com/2023/10/postgres-vs-mysql-impact-of-cpu.html
[8] StackOverflow开发者调查:
https://survey.stackoverflow.co/2023/#technology-most-popular-technologies
[9] MySQL性能越来越差，Sakila将何去何从？:
https://pigsty.cc/zh/blog/db/sakila-where-are-you-going/
[10] MySQL 的正确性为何如此垃圾？:
https://pigsty.cc/zh/blog/db/bad-mysql/
[11] Is Oracle Finally Killing MySQL?:
https://www.percona.com/blog/is-oracle-finally-killing-mysql/
[12] Can Oracle Save MySQL?:
https://www.percona.com/blog/can-oracle-save-mysql/
[13] Sakila, Where Are You Going?:
https://www.percona.com/blog/sakila-where-are-you-going/
[14] Postgres vs MySQL: the impact of CPU overhead on performance:
https://smalldatum.blogspot.com/2023/10/postgres-vs-mysql-impact-of-cpu.html
[15] Perf regressions in MySQL from 5.6.21 to 8.0.36 using sysbench and a small server:
https://smalldatum.blogspot.com/2024/02/perf-regressions-in-mysql-from-5621-to.html

END