Loading... # 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. 开发模式对比 ```mermaid 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. 关键技术问题 | 版本 | 问题 | 影响 | |------|------|------| | MySQL 8.0.29 | ALTER TABLE 默认 in-place 有边界情况缺陷 | 数据库崩溃、数据损坏 | | MySQL 8.0.32 | 一年后才完全修复 | 用户数据风险持续 | | MySQL 8.1 | 仅作为短期预览版本 | 功能不完整 | | MySQL 8.4 LTS | 新功能极少 | 用户失望 | | MySQL 9.5 | 写密集型工作负载性能下降 15% | 性能退化 | ### B. 版本发布问题 - 8.0 系列被宣布为"常青"版本 - 小版本引入功能变更而非仅修复 Bug - 6 年无新的主要版本（2018-2024） - 升级路径困难（5.7->8.0、8.0->8.4） - 大量功能废弃导致迁移复杂 ### C. 性能退化对比 ```mermaid graph LR A[MySQL 8.0] -->|基线性能| B[100%] B -->|MySQL 9.5| C[85%] C -->|下降| D[15%] D --> E[工作负载: 写密集型] ```  ## 3. 安全与透明度 ### A. CVE 数量对比（2025） | 数据库 | CVE 数量 | 独有 CVE | |--------|---------|----------| | MySQL | 123 | 117 | | MariaDB | 8 | - | ### 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. 安全影响分析 ```mermaid 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 发行版可通过简单命令安装： ```bash 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. 迁移决策流程 ```mermaid 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](https://optimizedbyotto.com/post/reasons-to-stop-using-mysql/) 最后修改：2026 年 01 月 24 日 © 允许规范转载 赞 如果觉得我的文章对你有用，请随意赞赏