为什么 MySQL 不是最流行的数据库？
作者介绍
司马辽太杰，10 余年互联网、金融、运营商等行业数据库管理经验，擅长常见关系型、NoSQL、MPP 、云原生等类型数据库的架构设计和运维管理。工作之余，热爱历史、足球，也喜欢读点闲书。欢迎关注我的个人公众号“程序猿读历史”。
MySQL 真的不再是最流行的吗？ MySQL 为什么不流行了？ MySQL DBA 们怎么办？
Google Trends
Google Trends 是基于全球最大搜索引擎的真实查询日志分析结果，覆盖主要国家和地区，比较直观反映技术关键词在全球范围内的关注度变化，被广泛用于技术趋势、市场热度和用户兴趣的长期对比分析。
图1：Google Trends
从Google Trends 可以看出 ¹，最近几年全球 MySQL 的搜索热度整体呈缓慢下降趋势，而 PostgreSQL 的关注度逐步追近，并在2025年中出现反超。
或许有人认为搜索引擎数据不够专业、难以代表数据库从业者的真实判断，那可以参考更具权威性的指标，比如数据库权威榜单 DB-Engines、开发者问答社区 Stack Overflow，以及顶级开发工具厂商 JetBrains 发布的年度分析报告。
DB-Engine
DB-Engines 是全球知名的数据库流行度排行榜，通过搜索引擎搜索量、技术文档、讨论热度、招聘需求、社交媒体提及以及厂商与社区关注度等多项指标进行排名，其排名不代表产品性能优劣，反映的是产品生态活跃度与行业关注程度。
图2：DB-Engines
从 DB-Engines 的数据来看 ²，MySQL 依然在榜单中位居第二，但从22年 AI 爆发以来，在该榜单中肉眼可见的速度下降。与此同时，PostgreSQL 的评分则持续稳步上升，二者差距不断缩小。
StackOverflow
Stack Overflow 2025 年对全球9万余名的开发者调查中 ³，结果显示在全部受访者中，PostgreSQL 使用率达到 55.6%， MySQL 为 40.5%；在专业开发者群体中，MySQL 使用率约 39.6%，而 PostgreSQL 为 58.2%，差距被进一步拉开。
图3：Stack Overflow
结合 Stack Overflow 历史数据来看，MySQL 曾在 2018 年达到约 59% 的高峰，7 年间下降近 19 个百分点，而 PostgreSQL 则持续稳步上升，并在近年实现反超。
JetBrains
JetBrains 作为全球主流开发工具厂商，在其发布的《2025 开发者生态系统报告》中也给出了相似结论 ⁴。该报告覆盖来自 194 个国家的 24534 名开发者，数据显示 MySQL 使用率为 49%，位列第二。
图4：JetBrains
国内变化
前面的相关数据是主要是针对海外数据库市场的分析，国内因为自主可控带来的信创市场的客观需求，情况则更为复杂。
墨天轮是国内知名的数据库技术社区与产业研究平台。根据其相关数据看 ⁵，国产数据库起源内核直接基于 PostgreSQL 的产品有 13 个，如果把 openGauss、Greenplum、HAWQ 等 PostgreSQL 生态衍生路线纳入统计，PG 系产品总数达 31 个；相比之下，基于 MySQL 内核的国产数据库仅 9 个，整体规模和生态广度均明显低于 PG 系。
图5：墨天轮数据
国产数据库中，不仅 PG 系产品数量更多， 在党政等体制内等领域落地案例也更丰富和成功，而国内的 MySQL 系更集中在互联网、游戏高并发等领域。
图6：头条指数
但如果只看国内数据库的流行度，Google的国内搜索指数、头条指数 ⁶、微信指数，以及笔者私下从国内最大云厂商的得到小道消息，MySQL 依旧大幅度领先其他数据库，是国内开发者、用户最受欢迎的数据库，甚至没有之一。
小结
因此，综合 Google Trends、DB-Engines、Stack Overflow、JetBrains 以及国内的墨天轮、头条指数、云厂商数据来看。在全球范围内，尤其是国内市场，MySQL 依然非常流行，但全球最流行的数据库这一定语值得讨论。那自然会问一句，海外为什么 MySQL 不像过去那么流行了？
答案其实很简单，时代在变，客户需求也在变。而在 Oracle 这位强势“后妈”的照看下，开源 MySQL 依然专注于纯粹的 OLTP 场景，稳稳守着自己的优势边界，既不冒进，也不越界。
企业：需求变了
互联网时代，企业对数据库需求是构建可靠的在线交易系统，支撑海量订单、用户处理。MySQL 凭借架构简洁易用、运行稳定以及出色的并发事务处理能力，精准契合互联网需求，迅速成为全球互联网公司的主流选择。这一技术惯性也延续至云计算时代，RDS MySQL 几乎成为各大云厂商的现金奶牛。可以说过去二十余年，MySQL 无疑是全球最成功、影响力最广泛的数据库产品之一。
但今天，企业对数据库的需求已经发生了根本变化。数据库不仅要支撑高并发交易，还必须在交易发生的同时，实时完成反欺诈、营销分析、推荐计算与业务，还能够处理文本、音频图、向量、空间地理、时序等多种数据形态。这就要求数据库从单一的交易引擎演进为统一的数据处理与计算平台，典型的既要、还要、还要。
图7：IDC 分析报告数据规模
根据 IDC 分析报告 ⁷，2024 年全球数据总量已达到 149 ZB，并将在 2025 年突破 181 ZB，其中约 80% 为文档、音频图等非结构化数据。从规模看，从2024到2028五年间生成的数据量将至少是过去10年生成的数据总量的2.2倍，约为过去5年生成的数据总量的2.9倍；从延迟看，其中22%的数据延迟在200毫秒以内。
图8：IDC 分析报告数据延迟
因此，今天企业对数据库需求已不再只是解决海量交易的问题，而是同时面临数据规模爆炸、数据类型高度多样化，以及对实时处理能力的刚性需求。
但从技术能力上看，开源 MySQL 仍然明显偏向传统 OLTP 设计，缺乏列式存储、并行计算、物化视图、哈希连接、位图索引、向量化执行引擎等关键 OLAP 能力，也缺乏对多模数据类型与混合检索场景的系统性支持。这使得它在面对今天的企业数据库要求的既要、又要、还要的需求面前，显得力不从心。
那既然企业要求据库既要、又要、还要，为什么 MySQL 不去满足呢？这当然不是技术问题，不得不提 MySQL 的“后妈” 、全球商业数据库& 云计算& AI 基础设施的霸主 Oracle 公司了。
Oracle：后妈不好做
2010 年，Oracle 以 10 亿美元天价收购 MySQL，这一交易让甲骨文不得不直面幸福的烦恼：如何在不自我竞争的前提下，完成全球最成功的商业数据库 Oracle Database，与全球最成功的开源数据库 MySQL 的产品准确定位。Oracle 这位霸总式后妈，既要讲开源情怀，也要算商业账，实在是难。
当然，从过去15年发展看，甲骨文用行动表示：Oracle Database 继续深耕高端企业级与复杂分析场景，而开源 MySQL 则被明确定位为稳定、高效的通用 OLTP 数据库，两者各守其位，互不越界。如果只看不同版本的 MySQL，那么社区版负责长期稳定与基础可用性，而关键能力、前沿特性和差异化竞争力，则集中在 MySQL Enterprise、HeatWave 以及 OCI 上的产品体系中。
MySQL Enterprise 在安全、审计、监控和运维工具链上持续增强，提供了TDE 透明数据加密、审计日志、企业级备份、高可用与合规能力，更符合大型企业的生产与监管需求；而 MySQL HeatWave 则通过内存列式引擎、向量化执行、MPP 架构与云基础设施的深度耦合，将分析型负载直接下沉到数据库内部，显著提升了实时分析、多模计算与 AI 推理场景下的性能与一体化能力 ⁸。
图9：来自 MySQL HeatWave Document
因此，对于Oracle 公司来说，开源 MySQL 不是不行，而仅仅是一家商业公司对内部相同产品在不同版本上的定位不同。相比之下，对于完全由社区控制的PostgreSQL 选择了一条完全不同的道路，核心能力与前沿特性持续在社区中演进，扩展生态不断反哺内核，不设明显的能力围栏。
从这个角度看，开源 MySQL 并不是技术失败，而是被一家商业公司明确定位为一款成熟、稳定、专一的 OLTP 产品，而完全由社区控制的 PostgreSQL 则拥抱时代的变化，核心能力逐步跟上时代的需求。这种战略选择的差异，正是开源 MySQL 在海外流行度变化的根本原因。
小结
实际上，MySQL 并非衰落，而是停留在了它最擅长的时代。随着企业数据库需求从单一 OLTP 向混合负载、多模型与实时分析演进，开源 MySQL 的能力边界逐渐显现，而 Oracle 将创新集中于商业版与云产品，使社区版难以跟上需求变化。相比之下，持续演进、能力开放的其他关系型数据库更适合新时代诉求。
首先不必要焦虑，至少国内 MySQL 依然是最流行、最成熟的数据库。在 OLTP 场景，其稳定性、生态成熟度和性价比短期内难以被彻底替代。但也必须正视一个现实：开源 MySQL 正逐渐成为一项存量技术，短期不会消失，却很难再成为技术创新和能力溢价的核心来源。
这意味着，MySQL DBA 的价值边界正在发生变化。如果能力仍停留在传统运维范畴：参数调优、主从复制、备份恢复、容量规划与故障处理，职业天花板会越来越清晰，替代性也会越来越强。在云计算、自动化运维和 AI 不断成熟的背景下，单一 MySQL 运维技能正在被持续产品化、商品化、。
无他，唯学习尔
对于今天的 IT 从业者而言，持续学习不再是加分项，而是一种与吃饭、睡觉、喝水同等重要的基本生存能力。可以武断地说，在当前的科技公司，没有任何一个技术岗位可以躺在过往的成功经验之上，更何况是一个技术红利正在收敛的 MySQL DBA 角色。
企业对数据库需求加速向多模数据、混合负载、AI 方向演进，企业对 DBA 的期待自然已不再局限于把 MySQL 运维好，而是能够理解业务负载特征、数据架构演进路径以及系统整体性能边界的数据库工程师。
这要求 MySQL DBA 走出传统 OLTP 运维视角，系统性理解更完整的 SQL 体系、高并发事务的实现原理、执行器与优化器的设计思想，并熟悉数据库的扩展机制。同时，还需要主动补齐分析型数据库的核心能力认知，包括列式存储、向量化执行、多模数据结构、MPP 架构、HTAP 设计以及云原生等关键技术，而不是停留在传统某一个数据库运维。
图10，来自：MySQL Document
从更高层次看，数据库在架构上都可以抽象为三层：接入层、引擎层和存储层。接入层负责连接协议解析、连接管理、权限认证，引擎层负责 SQL 解析、优化与执行（Parser / Optimizer / Executor），存储层负责数据结构、并发控制、持久化以及事务一致性， MySQL ⁹ 和市场上绝大多数主流数据库都遵循这一架构。
因此，深入理解 MySQL 的内部机制，实际上是打通了数据库学习的任督二脉本，再学习其他数据库，往往可以事半功倍。与其纠结某一款数据库的流行与否，不如把精力投入到数据库底层原理与系统能力的构建之上。
另外，从产品流行度、能力以及生态的丰富度，学习开源 MySQL 依然是最好的起点，但在未来肯定不再是能力的终点。站在更高的系统视角，理解不同数据库在架构与取舍上的共性与差异，才能在企业数据库技术持续演进中，保持个人长期不可替代的价值。
如果你仍然担心转向其他数据库体系的学习成本过高，不妨关注一位对 MySQL DBA 极其友好的，又能同时满足现代企业既要、又要、还要的国产、开源数据库：OceanBase。
Super MySQL：OceanBase
如果说开源 MySQL 在 Oracle 公司的战略下，能力边界被长期固定在纯 OLTP 场景，那么 OceanBase 的思路恰恰相反，在 MySQL 兼容的基础上，把企业既要、又要、还要的需求逐步内建进 OB 数据库内核。
首先在 OLTP 能力上，OB 并不是另起炉灶，通过 MySQL 兼容（当然也有Oracle 兼容版本），在 SQL 语法、事务模型、索引、应用接入方式以及运维习惯上，对 MySQL DBA 保持高度友好。再结合 OB 分布式共识协议、多副本一致性无主架构，在高并发写入、跨节点事务和高可用方面，解决了单机 MySQL 在规模化场景下的天然瓶颈问题。
当然 OB 的关键差异并不只是把 OLTP 做得更大，而是持续引入多模、混合负载、混合搜索能力。来满足企业对数据库的需求。
OceanBase 列存存储引擎设计
在混合负载场景，OB 通过列存、向量化执行引擎、物化视图、更丰富的算子和统计信息等技术能力 ¹⁰ ，实现在同一套数据上同时支撑事务处理与复杂分析，避免了传统 MySQL 架构实现实时分析、风控计算、业务监控等场景需要依赖外部 OLAP 系统。
在多模数据形态需求，OB 也沿着企业真实需求逐步演进。JSON、空间数据、全文与半结构化数据能力不断增强，使数据库可以承载更多业务数据形态，而不只是结构化交易表。这一点，正好补齐了 MySQL 在新型业务数据处理上的短板。
与此同时，OceanBase 从架构层原生支持多租户、资源隔离与弹性伸缩能力，使其在云环境和大型企业场景下，可以同时服务多业务、多部门甚至多客户，而不需要像 MySQL 那样通过多实例来实现。这种能力是内核级设计，直接影响系统稳定性与运维复杂度。
作为一名数据库从业者以及 OB 外部人士，结合过去几年的 OB 发展看：OB 并不是试图在某一个维度碾压 MySQL，而是回答了一个 MySQL 长期难以解决的问题：能否在 MySQL 熟悉的技术体系内，原生满足企业对事务、分析、实时计算与规模化的一体化诉求。
综合来看，MySQL 并未衰落。无论在全球还是国内市场，它依然是很流行的数据库之一，并且在 OLTP 场景下具备难以替代的稳定性、性能和生态优势，短期内不存在被全面取代的可能。从学习投入产出比来看，MySQL 仍然是数据库领域性价比高、适合作为技术起点的选择。
而对于 MySQL 在是否符合今天企业需求的争议，本质并非技术能力不足，而是 被 Oracle 收购后的战略定位问题。社区版 MySQL 被长期限定在通用 OLTP 领域，而多模、分析、AI 等前沿能力被集中到商业版与云产品中。
对于 MySQL DBA 而言，也不必纠结 MySQL 产品行不行，而是应该思考 MySQL DBA 是否仍选择停留在原地；更不必纠结 MySQL 会不会消失，但也要承认单一 MySQL 运维为核心的高价值时代正在远离。