MySQL 在 2026 年不再是真正的开源软件技术分析

一、新闻概述

1. 标题

停止在 2026 年使用 MySQL，它不是真正的开源软件

2. 发布时间

2026 年 1 月 11 日

3. 来源

Optimized by Otto

二、核心内容

1. 事件摘要

A. 主要内容

Otto Kekalainen 发布文章呼吁在 2026 年停止使用 MySQL，转而使用 MariaDB。文章指出 MySQL 虽然使用 GPL 开源协议，但并非真正的开源项目，开发过程完全闭门进行，社区贡献受到限制。

B. 核心亮点

• MySQL GitHub 提交量在 2025 年显著下降
• Oracle 收购后 MySQL 社区逐渐萎缩
• MySQL 技术质量从 2022 年开始明显下滑
• 2025 年 MySQL 公布 123 个 CVE，而 MariaDB 仅 8 个

2. 关键信息

A. 涉及产品

• MySQL 8.0/8.4/9.5
• MariaDB
• Percona Server
• TiDB

B. 重要数据

• 2025 年 MySQL CVE 数量：123 个
• 2025 年 MariaDB CVE 数量：8 个
• 全球 57% 的 WordPress 网站使用 MariaDB
• MySQL 9.5 写密集型工作负载吞吐量比 8.0 下降约 15%

C. 历史背景

• 2009 年 Oracle 收购 Sun Microsystems 和 MySQL
• 2018 年 MySQL 8.0 发布
• 2024 年 MySQL 8.4 LTS 发布
• 2025 年 Oracle 大幅削减 MySQL 团队人员

三、详细报道

1. 开源性质问题

A. 开发模式对比

graph LR
    subgraph MySQL_开发模式
        M1[Oracle 内部开发] --> M2[闭门开发]
        M2 --> M3[社区提交 PR]
        M3 --> M4[无反馈/被忽略]
        M4 --> M5[发布新版本]
    end

    subgraph MariaDB_开发模式
        N1[GitHub 公开开发] --> N2[实时审查]
        N2 --> N3[社区参与讨论]
        N3 --> N4[Jira 公开追踪]
        N4 --> N5[透明发布]
    end

B. MySQL 社区问题

• 所有开发在闭门环境中进行
• 公开 Bug 跟踪器并非 Oracle 实际使用的系统
• 社区提交的 Pull Request 缺乏反馈
• 代码变更通常被重写，原作者仅在博客中获小额提及
• Git 作者/提交者字段仅包含 Oracle 员工

C. MariaDB 开放模式

• 所有开发在 github.com/mariadb/server 实时进行
• 任何人都可以提交 Pull Request 并获得审查
• 所有 Bug 在 jira.mariadb.org 公开讨论
• 符合真正开源项目的运作模式

2. 技术质量下滑

A. 关键技术问题

B. 版本发布问题

• 8.0 系列被宣布为"常青"版本
• 小版本引入功能变更而非仅修复 Bug
• 6 年无新的主要版本（2018-2024）
• 升级路径困难（5.7->8.0、8.0->8.4）
• 大量功能废弃导致迁移复杂

C. 性能退化对比

graph LR
    A[MySQL 8.0] -->|基线性能| B[100%]
    B -->|MySQL 9.5| C[85%]
    C -->|下降| D[15%]
    D --> E[工作负载: 写密集型]

3. 安全与透明度

A. CVE 数量对比（2025）

B. 安全处理方式差异

MySQL：

• CVE 描述缺乏详细信息
• 示例：CVE-2025-53067 仅说明"高权限攻击者可通过多种协议轻易利用"
• 无可验证的漏洞细节
• 用户必须信任 Oracle 声称已修复
• 典型描述："Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server"

真正的开源项目：

• 安全问题在禁运期结束后完全公开
• 代码修复可供全面审查
• 可验证漏洞存在性和修复有效性
• 社区可审查修复方案是否充分

C. 安全影响分析

graph TD
    A[闭源安全处理] --> B[缺乏详细信息]
    B --> C[无法验证漏洞]
    C --> D[无法审查修复]
    D --> E[完全依赖供应商信任]
    E --> F[增加安全风险]

    G[开源安全处理] --> H[完整漏洞信息]
    H --> I[代码公开可审]
    I --> J[社区验证修复]
    J --> K[降低安全风险]

4. 社区与生态系统

A. DB-Engines 排名趋势

• MySQL 受欢迎度在 2024 年开始大幅下滑
• 2026 年预计加速下跌

B. 开发活跃度下降

• GitHub 提交量在 2025 年显著减少
• Oracle 于 2025 年 9 月大幅削减 MySQL 团队
• 最新维护版本包含的 Bug 修复数量较之前减少

C. 商业化压力

• Oracle 将用户推向闭源版本
• Heatwave 作为云专有服务推广
• MySQL 网站和文档引导用户远离开源版本
• Reddit 反馈显示用户被迫"付出更多获得更少"

四、迁移选项分析

1. MariaDB（推荐）

A. 优势

• 真正的开源项目
• 由 MySQL 原作者 Michael "Monty" Widenius 创建
• 高度向后兼容 MySQL
• 开发透明，社区活跃
• 大量应用已迁移

B. 采用情况

• Wikipedia 等大型安装
• Fedora、Debian 等 Linux 发行版
• 全球 57% 的 WordPress 网站使用 MariaDB
• MySQL 份额为 42%

C. 迁移难度

• 对于 LAMP 应用（WordPress、Drupal、Mediawiki、Nextcloud、Magento）直接替换
• 现有连接器和数据库客户端无需修改

• Linux 发行版可通过简单命令安装：

  apt/dnf/brew install mariadb-server

2. PostgreSQL

A. 优势

• 最流行的通用开源数据库
• 功能丰富，社区强大
• 高度可扩展

B. 挑战

• 从 MySQL 迁移需要大量工作
• 架构差异显著
• 需要重写 SQL 语句

3. Percona Server

A. 优势

• 紧密跟踪 MySQL 变更
• 仅进行少量改进
• 迁移简单

B. 局限

• 仍是 MySQL 定制版本
• 未脱离 Oracle 依赖
• 非长期解决方案

4. TiDB

A. 优势

• 从头设计，高度可扩展
• 与 MySQL 兼容
• 适用于大型分布式系统
• Amazon DSQL 借鉴其设计

B. 适用场景

• 大型分布式设置
• 需要高可扩展性的系统

C. 挑战

• 对于小型和中型应用可能过于复杂
• 资源要求较高

5. 迁移决策流程

graph TD
    A[当前使用 MySQL] --> B{应用类型}
    B -->|LAMP 应用| C[选择 MariaDB]
    B -->|自定义应用| D{优先级}

    D -->|快速迁移| C
    D -->|长期独立| E{考虑因素}

    E -->|高性能/可扩展性/复制| C
    E -->|通用功能| F[PostgreSQL]
    E -->|分布式大型系统| G[TiDB]

    C --> H[安装: apt/dnf/brew install mariadb-server]
    F --> I[重写 SQL，调整应用]
    G --> J[评估资源需求]

五、影响分析

1. 行业影响

A. 开源软件信任

• MySQL 案例凸显许可证与开发实践的区别
• GPL 许可证不保证真正的开源开发模式
• 可能影响用户对 Oracle 管理的其他开源项目信任

B. 数据库市场格局

• PostgreSQL 可能继续增长
• MariaDB 获得 MySQL 转移用户
• 专用云数据库服务（如 Heatwave）与传统开源软件竞争

2. 用户影响

A. 现有 MySQL 用户

• 需要评估迁移策略
• 考虑长期支持和安全更新
• 评估性能退化对业务的影响

B. 新项目选择

• 优先选择真正的开源数据库
• 考虑社区活跃度和透明度
• 评估长期可持续性

C. 商业考量

• 避免 Oracle 供应商锁定
• 降低"付出更多获得更少"的风险
• 保护数据主权和安全

六、各方反应

1. 专家观点

A. Peter Zaitsev（Percona）

• 2024 年 6 月发文《Oracle 终于要杀死 MySQL 吗》
• 2025 年 11 月统计显示最新维护版本 Bug 修复减少
• 对 MySQL 未来表示担忧

B. Mark Callaghan（MySQL 性能专家）

• 基准测试显示新版本性能退化
• MySQL 9.5 写密集型工作负载吞吐量下降 15%

2. 社区反馈

A. Reddit 讨论

• 用户抱怨升级困难
• 被迫为越来越少的功能支付更多费用
• 对 Oracle 管理的 MySQL 失去信心

B. 企业实践

• Amazon AWS 工程团队更倾向于贡献 MariaDB
• 大型安装（如 Wikipedia）已迁移到 MariaDB
• Linux 发行版默认使用 MariaDB

3. 技术趋势

A. 开源定义讨论

• 许可证 vs 开发实践
• 透明度的重要性
• 社区参与的价值

B. 安全意识提升

• 闭门开发的安全风险
• CVE 处理透明度的重要性
• 供应商信任问题

七、技术建议

1. 评估当前使用

• 审计所有 MySQL 实例
• 评估迁移成本和风险
• 确定迁移优先级

2. 迁移规划

• 选择目标数据库（推荐 MariaDB）
• 制定详细迁移计划
• 在测试环境验证
• 准备回滚方案

3. 长期策略

• 投资真正的开源项目
• 参与社区贡献
• 避免供应商锁定
• 保护数据主权

参考资料

1. Stop using MySQL in 2026, it is not true open source - Optimized by Otto