如果你重视开源软件生态，却在2026年仍在使用MySQL，那么像许多先行者一样，转向MariaDB或许是一个更明智的选择。
github.com/mysql/mysql-server 上的Git提交数量在2025年显著下降。下图展示了截至2026年1月的现状，这对于任何关注软件是否真正开源的人来说，都应引起警惕。
这并不意外——甲骨文作为开源项目守护者的角色备受质疑
早在2009年甲骨文收购Sun Microsystems及其旗下的MySQL时，欧盟委员会就曾因担忧其扼杀竞争而几乎阻止这笔交易。交易最终因甲骨文承诺继续维护MySQL而得以放行，但结果（毫不意外地）是，甲骨文并未成为MySQL开源项目的合格守护者，其社区生态多年来持续萎缩。
所有的开发都在封闭环境中进行。 公开可见的漏洞追踪器并非甲骨文内部实际使用的系统。少数尝试贡献代码的开发者，其提交的Pull Request和补丁往往仅被标记为“已接收”，随后便石沉大海，鲜有反馈。即便这些改动最终被采纳，也常常被重写，且Git提交记录中的作者信息仅显示甲骨文员工。真正的贡献者，往往只在版本发布的博客文章中被一笔带过。
我曾担任亚马逊云服务（AWS）负责RDS MySQL和RDS MariaDB核心团队的工程经理，期间监督了团队对两者的代码贡献。我们发现，无论是功能开发还是问题修复，甲骨文对社区贡献的响应都极为冷淡，这导致团队所有开发者都不愿向MySQL提交代码。
相比之下，MariaDB则截然不同。所有开发都在 github.com/mariadb/server 上实时公开，任何人都可以提交Pull Request并获得审查，所有问题都在 jira.mariadb.org 公开讨论，完全符合一个真正开源项目的运作模式。MySQL仅在许可证（GPL v2）上是开源的，但作为一个协作项目，它早已名存实亡。
MySQL近年来的技术衰落
平心而论，甲骨文在收购后的十多年里确实维持了MySQL的存续与版本更新。然而，这无法掩盖其作为开源守护者的失职，也无法阻止MySQL自2022年起在技术层面出现明显的倒退迹象。
当MySQL 8.0.29将默认的 ALTER TABLE 操作改为“就地”（in-place）执行后，触发了多个边界情况，导致部分用户数据库崩溃甚至数据损坏。这一问题直到一年后的MySQL 8.0.32才被完全修复。更令用户困扰的是，甲骨文将8.0系列宣布为“常青树”，却在次要版本中引入新功能，而非像以往那样专注于漏洞修复。
MySQL经历了长达五年的主版本空窗期。 自2018年发布MySQL 8.0后，直到2023年才推出短期预览版MySQL 8.1。首个真正的新主版本MySQL 8.4 LTS于2024年发布，但这个让用户等待已久的版本却因新功能寥寥无几而令人失望。
性能问题也开始浮现。例如，知名MySQL性能专家Mark Callaghan的基准测试显示，在写入密集型负载下，MySQL 9.5的吞吐量较8.0下降了约15%。
由于新版本弃用了大量旧功能，用户普遍反映从MySQL 5.7升级至8.0，以及从8.0升级至8.4的过程异常艰难。新功能匮乏，重点却放在代码清理和功能弃用上，这使得许多人意识到，甲骨文可能已决定仅维持MySQL的“最低生存状态”，而将所有重要的创新功能（如向量搜索）都置于其闭源且仅限云端的Heatwave服务中。
种种迹象表明甲骨文已不再对MySQL进行实质性投入。Percona的Peter Zaitsev在2024年6月撰文《甲骨文终于要杀死MySQL了吗？》，尖锐地提出了这一问题。此时，MySQL在 DB-Engines 的流行度排名也已开始大幅下滑，这一趋势很可能在2026年加速。
2025年9月，有报道称甲骨文正在裁员，MySQL团队首当其冲。这显然不是个好兆头。Peter Zaitsev在同年11月发布的数据也显示，最新的MySQL维护版本所包含的漏洞修复数量已大不如前。
开源不止是理念：它对软件安全与主权有切实影响
有人认为，只要MySQL现在还能用，就不在乎它是否真正开源或有无未来。这种观点可能忽视了潜在的重大风险。数据库通常是软件架构中最核心的组件，任何操作故障，尤其是安全问题，都可能带来即时且严重的后果。对开源价值的漠视，长远来看可能引发运营危机甚至法律风险。
在开源模式下，问题被公开讨论，越严重的问题越能吸引广泛的社区力量共同解决。开源开发模式类似于科学方法，思想自由流动、不断接受验证，唯有最具说服力的方案才能胜出。反之，封闭则意味着不透明、更高的风险，以及“请相信我们”的傲慢态度。
这种开放与封闭的差异，在安全漏洞的处理上体现得淋漓尽致。2025年，MySQL发布了多达123个安全漏洞（CVE），而 MariaDB仅有8个。其中，有117个CVE仅影响MySQL。这些CVE的描述往往含糊其辞，以最近的 CVE-2025-53067 为例，它仅称“高权限攻击者可通过多种协议危害MySQL服务器”，完全没有提供可供安全研究人员或审计人员验证漏洞细节、修复是否充分的有效信息。MySQL用户只能选择相信甲骨文的单方面声明。这与主流开源项目在保密期过后公开漏洞详情及修复代码的做法形成了鲜明对比。
此外，MySQL的软件、文档及官网都在有意引导用户放弃开源版本，转向闭源版本乃至完全由甲骨文控制的Heatwave云服务。这种“服务品质下降”（Enshittification）的趋势，在真正的开源项目中是难以想象的。
当然，有人会认为这是甲骨文的商业模式。但 Reddit 等社区的反馈显示，实际情况更像是甲骨文在不断压缩对MySQL投入的同时，迫使剩余的付费客户支付更高的费用以换取更少的价值。
选择众多，迁移简便，行动正当其时
事实上，早在2010年代中期，大批重视数据库软件开源属性的用户（包括维基百科、Fedora、Debian等）就已转向MariaDB。由于开源软件缺乏统一的统计数据，我们无法获知确切的市场份额，但可以从具体应用中窥见一斑：例如，在全球 57%的WordPress网站运行在MariaDB上，而MySQL的份额为42%。
对于运行WordPress、Drupal、MediaWiki等经典LAMP（Linux, Apache, MySQL/MariaDB, PHP）技术栈应用的用户而言，将MySQL替换为MariaDB通常非常直接。因为MariaDB是MySQL的分支，并保持了高度向后兼容性，替换后通常无需修改应用连接代码。
对于可以自由选择技术栈的自定义应用，则有数十种成熟的开源数据库可选，其中PostgreSQL是最流行的通用选择。但如果应用深度绑定MySQL特性，迁移至PostgreSQL可能工作量巨大。此时，基于相同架构（如InnoDB存储引擎）的MariaDB，在某些对性能、扩展性和复制能力要求极高的场景下，可能仍是更平滑的选择。
从MySQL迁移到Percona Server也非常容易，因为它紧密跟随MySQL的更新。但正因为其本质是MySQL的定制版，对于希望彻底摆脱甲骨文体系的用户来说，它并非长期的终极解决方案。
还有一些与MySQL无血缘关系但力求兼容的数据库，如专为大规模分布式系统设计的 TiDB。它非常优秀，甚至影响了亚马逊DSQL的设计。不过，TiDB的优势在大型分布式架构中才能充分发挥。对于绝大多数正在使用MySQL的中小型应用而言，最务实、快捷的方案可能就是切换到MariaDB——在大多数Linux发行版上，只需运行 apt/dnf/brew install mariadb-server 即可完成安装。
综上所述，从开源协作、技术活力、安全透明及长期可持续性角度评估，考虑迁移至MariaDB或其他活跃的开源数据库，对于许多用户而言可能是一个更为明智的选择。
原文链接：https://optimizedbyotto.com/post/reasons-to-stop-using-mysql/
