MySQL 9.0发布，为何被指责为创新不足？

本月，MySQL 9.0 正式发布（@2024-07），距上次 8.0 大版本更新（@2016-09）已有八年。但这个所谓的创新版却空洞无物，像个糟糕的玩笑，昭示着 MySQL 或将逐渐退出历史舞台。
PostgreSQL 发展迅猛，而 MySQL 的辉煌似乎正在褪去。作为 MySQL 生态的重要支持者，Percona 也不得不面对这一现实，并连续发表三篇文章——MySQL 的未来在哪里Oracle 是否最终扼杀了 MySQL以及Oracle 还能拯救 MySQL 吗，明确表达了对 MySQL 当前状况的失望与无奈。这些文章反映了 MySQL 面临的挑战及其在行业中的地位变化，引发了广泛的关注与思考。
Percona公司首席执行官彼得·扎伊采夫也表示：
有些数据库正在蓬勃发展，占据越来越大的市场份额，而有些数据库却在逐渐衰落，走向消亡。

MySQL 官网发布的MySQL 9.0 新特性文章，介绍了该版本新增的几项功能。另一篇关于 MySQL 9.0 新功能概览的文章则对这些内容进行了简明总结，便于读者快速了解其核心更新点。

就这些了吗？不会再有别的了吗？
这确实令人惊讶，因为 PostgreSQL 每年发布的新版本都会带来众多功能更新。例如，今年秋季即将发布的 PostgreSQL 17 目前仅处于 beta1 阶段，但其新增特性清单已十分庞大，令人瞩目。

近几年，PostgreSQL的新特性丰富到足以写成一本书。例如，快速掌握PostgreSQL版本新特性就汇总了近七年的关键更新，内容涵盖广泛，目录充实饱满，展示了这个数据库的持续进化与强大功能扩展。

再看MySQL 9更新的六大特性，后四项 merely 无足轻重，不值一提。真正值得关注的是前两项：向量数据类型与JS存储过程，这才是极具分量的亮点所在。

MySQL 9.0 的向量数据类型不过是 BLOB 类型的变体，仅新增了数组长度函数。这类功能在 28 年前 PostgreSQL 诞生时就已经支持了。
MySQL的JavaScript存储过程支持竟为企业版专属，开源版无缘。而类似功能，PostgreSQL 9.1早在13年前就已实现。这让人不禁思考其中的差距与选择的代价。
时隔八年的大版本更新，却只带来两个老特性，其中一个还是企业版专属。创新二字在此显得格外讽刺。
近两年，AI热潮推动了向量数据库的发展。目前，几乎所有主流数据库管理系统都已支持向量数据类型，唯独MySQL尚未跟进。
用户原本期待9.0创新版的向量支持能弥补不足，发布后却发现令人震惊——居然如此敷衍？
MySQL 9.0官方文档中，关于向量类型的函数仅有三个。除去用于与字符串相互转换的两个函数外，真正具备功能的只有一个：VECTOR_DIM。该函数用于返回向量的维度，其实就是计算数组的长度。

向量数据库的入门门槛其实非常低，只需实现一个向量距离函数即可（比如内积，用 C 语言写十几行代码，小学生都能完成）。这样就能通过全表扫描计算距离，再用 ORDER BY d LIMIT n 实现基本的向量检索功能，完全可用。然而，令人失望的是，MySQL 连这样一个简单的向量距离函数都懒得实现。这显然不是技术能力的问题，而是 Oracle 根本没有用心做 MySQL 的意愿。有经验的开发者一眼就能看穿，所谓的向量类型不过是 BLOB 的别名——它只负责存储二进制数据，完全不关心用户如何查询和使用。当然，也不能排除 Oracle 在自家的 MySQL Heatwave 中提供了更认真的实现，但在标准版的 MySQL 中，最终交付的功能就像一个十分钟随便敲出来的代码，敷衍了事，毫无诚意可言。
可以参考 MySQL 的老牌对手 PostgreSQL，它提供了更实在的案例。过去一年里，PG 生态系统中诞生了至少六种向量数据库扩展，例如 pgvector、pgvector.rs、pg_embedding、latern、pase 和 pgvectorscale。这些扩展在竞争中不断推动彼此进步。最终，2021 年就已发布的 pgvector 脱颖而出。得益于无数开发者、厂商和用户的共同支持，pgvector 借助 PostgreSQL 的强大基础，迅速达到了许多专业向量数据库难以企及的高度。可以说，pgvector 凭借自身实力，几乎让专用向量数据库这一细分领域失去了存在意义，正如文章标题所问：专用向量数据库凉了吗？。

过去一年中，pgvector 的性能提升了 150 倍，功能也发生了革命性的变化。如今，pgvector 提供了多种数据类型支持，包括 float 向量、半精度向量、bit 向量和稀疏向量。同时，它内置了多种距离度量方法，如 L1 距离、L2 距离、内积距离、汉明距离以及 Jaccard 距离。此外，pgvector 还实现了丰富的向量与标量计算函数及运算符。
在索引方面，pgvector 支持 IVFFLAT 和 HNSW 两种高效的向量索引算法，而扩展插件 pgvectorscale 更进一步引入了 DiskANN 索引技术。为了优化性能，pgvector 增加了并行索引构建功能，并支持向量量化处理和稀疏向量操作。此外，它还提供了子向量索引与混合检索能力，并可通过 SIMD 指令实现加速。
凭借这些强大且多样化的功能，再加上开源免费的协议，以及 PostgreSQL 生态系统的广泛协作，pgvector 成功脱颖而出。它与 PostgreSQL 一起，成为众多 AI 项目首选的向量数据库解决方案，为用户提供了卓越的性能和灵活性。
将 pgvector 与 MySQL 对比似乎不太恰当。MySQL 所谓的向量功能，甚至不如 1996 年 PostgreSQL 出现时就具备的多维数组类型。毕竟，PostgreSQL 拥有丰富的数组函数，而不仅仅是计算数组长度而已。
向量堪称新JSON，但向量数据库的风口已过，MySQL却还未入局——它再一次完美错失了未来十年AI时代的增长机遇，正如十年前错过互联网时代JSON文档数据库的发展浪潮一样。
MySQL 9.0 的另一大亮点是引入了 JavaScript 存储过程功能，为开发带来更多可能。
用 JavaScript 编写存储过程并非新鲜概念。早在 2011 年，PostgreSQL 9.1 就借助 plv8 扩展实现了 JavaScript 存储过程的编写，而 MongoDB 也在同一时期左右推出了对 JavaScript 存储过程的支持功能。这一技术已在数据库领域应用多年，为开发者提供了更多灵活性。
观察 DB-Engine 近十二年的数据库热度趋势可以发现，唯有 PostgreSQL 和 MongoDB 两款数据库管理系统脱颖而出。MongoDB（2009年）与 PostgreSQL 9.2（2012年）精准捕捉了互联网开发者的需求，在 JSON 格式兴起之初便迅速加入对 JSON 特性的支持，转型为文档型数据库。这一关键决策让它们在过去十年中占据了数据库领域最大的增长优势，成为行业内的领军者。这种敏锐的市场洞察力和快速的技术响应，使二者长期保持领先地位。

Oracle 作为 MySQL 的母公司，早在2014年底发布的12.1版本中，就已加入JSON功能和JavaScript存储过程支持。而MySQL自身直到2024年才姗姗来迟地补齐这一特性，可惜为时已晚，错失良机！
Oracle 支持使用 C、SQL、PL/SQL、Python、Java 和 JavaScript 编写存储过程。然而，相较于 PostgreSQL 所支持的二十多种存储过程语言，Oracle 也只能望其项背，略逊一筹了。

MySQL 的设计理念与 PostgreSQL 和 Oracle 存在差异，在其最佳实践中方针明确不建议使用存储过程。因此，对于 MySQL 来说，JavaScript 函数这一特性显得有些多余。即便如此，Oracle 仍将 JavaScript 存储过程支持作为 MySQL 企业版的专属功能推出。然而，由于大多数 MySQL 用户实际使用的是开源社区版本，这个特性的推出似乎并没有触及到主要用户群体，显得 somewhat 鸡肋且缺乏实际意义。
MySQL 的功能短板不仅体现在编程语言和存储过程支持上，从整体来看，它在多个方面都远落后于竞争对手 PostgreSQL。这种差距不仅存在于数据库内核功能中，还明显表现在扩展生态的丰富性和能力上。
卡内基梅隆大学的 Abigale Kim 研究了主流数据库的可扩展性。她发现，PostgreSQL 在所有数据库管理系统中具备最佳的可扩展性，并且其插件生态远超其他数据库系统。仅 PGXN 上就有 375+ 个实用插件，而实际生态中的扩展总数已超过千个，展现出强大的灵活性与适应能力。

这些扩展插件为 PostgreSQL 增添了丰富的能力，涵盖地理空间、时间序列、向量检索、机器学习、OLAP 分析、全文检索和图数据库等功能，使它成为全能型的全栈数据库。通过单一的 PostgreSQL 部署，即可替代多种专用技术组件，例如 MySQL、MongoDB、Kafka、Redis、ElasticSearch、Neo4j，甚至专门的分析数据仓库和数据湖，极大简化了技术选型与架构复杂度。

当 MySQL 仍被限定在关系型 OLTP 数据库的角色时，PostgreSQL 已经突破限制，从传统的关系型数据库演进为支持多模态的数据库系统，进一步发展成一个抽象的数据管理框架和开发平台。
PostgreSQL正逐步主导数据库领域，通过插件形式将各类数据库功能融入自身。如今，全用Postgres不再只是少数精英团队的前沿尝试，而已成为广受认可的主流最佳实践方案，展现了其强大的适应性和拓展性。
在新功能方面，MySQL 的表现却相当消极。本应充满重大变更的创新大版本更新，要么是敷衍了事的无用特性，要么是专为企业版打造的鸡肋功能，甚至一个大版本连零散的小修小补都凑不齐。
功能缺失或许并非不可逾越的障碍。对于数据库而言，只要其核心任务完成得足够出色，架构师便能通过额外努力，借助其他数据工具组合实现所需功能。
MySQL过去以其优异的性能为傲，特别是在互联网场景下的简单OLTP操作中表现突出。但如今这一优势正面临挑战。Percona的一篇博文Sakila：你将何去何从指出，一个令人震惊的结论是：……这表明MySQL在某些方面可能不再具备明显的技术领先性。
MySQL新版性能不如旧版。

Percona 的测试结果显示，在 sysbench 和 TPC-C 测试中，MySQL 8.4 的性能相比 MySQL 5.7 平均下降了约 20%。MySQL 专家 Mark Callaghan 通过深入的性能回归分析，验证了这一情况确实存在。这表明新版本在性能表现上仍有优化空间，可能需要进一步调整以满足用户需求。

虽然 MySQL 8.x 的优化器在部分复杂查询场景中有所提升，但分析型与复杂查询本就非其强项，改进也只能说是勉强够用。然而，作为核心优势的 OLTP 场景下 CRUD 性能如果出现显著下降，这显然是难以接受的问题，毕竟这是 MySQL 的基本盘所在。

彼得·泽特塞夫在文章Oracle终究还是放弃了MySQL中提到：相较于MySQL 5.6，8.x版本在单线程简单任务处理上的性能显著下降。有人可能认为，功能的增加必然会导致性能损失，但相比之下，MariaDB的性能降幅小得多，而PostgreSQL甚至在新增功能的同时实现了性能的大幅提升。

MySQL 在版本更新过程中性能逐渐下降，而 PostgreSQL 在相同的性能回归测试中则表现出随版本提升的稳定增长。尤其在核心的写入吞吐性能方面，最新版 PostgreSQL 17beta1 相较六年前的 PostgreSQL 10，提升了 30% 至 70%。这体现了 PostgreSQL 持续优化的技术优势。
通过 Mark Callaghnan 的 sysbench 性能对比测试（吞吐场景），我们发现五年前 PG 11 和 MySQL 5.6 的性能比例（蓝色）与如今 PG 16 和 MySQL 8.0.34 的性能比例（红色）存在显著差异。过去五年间，PostgreSQL 与 MySQL 的性能差距持续扩大，显示出两者在性能发展上的不同趋势。这一结果值得数据库用户深入思考和关注。

几年前，行业普遍认为在简单的 OLTP CRUD 场景中，PostgreSQL 和 MySQL 的性能相差无几。但随着时间发展，两者差距逐渐拉开，如今 PostgreSQL 的性能已显著超越 MySQL。在多种读取场景下，PostgreSQL 的吞吐量比 MySQL 高出 25% 至 100%。而在某些写入场景中，其吞吐量更是达到 MySQL 的 2 倍甚至 5 倍，展现出惊人的优势。这种性能提升使得 PostgreSQL 在处理大规模数据时更具竞争力。
MySQL曾经引以为豪的性能优势，如今已经消失不见。
性能不佳尚可优化补救，但若正确性出错，便 truly 无药可救了。
MySQL正确性问题有多严重？提到，作为体面数据库应具备的基本属性，MySQL在正确性方面的表现极为糟糕。
分布式事务测试机构 JEPSEN 的研究显示，MySQL 所宣称的可重复读（RR）隔离级别，其实际正确性远低于预期。在 MySQL 8.0.34 中，默认的 RR 隔离级别无法真正实现可重复读，甚至不具备原子性和单调性，连最基本的单调原子视图（MAV）标准也未能达到。这表明其隔离特性存在显著偏差。

MySQL 的 ACID 特性存在不足，未能完全兑现官方文档中的承诺。这种落差可能导致严重的数据正确性问题，如数据丢失、重复或账目不平。在金融等对数据完整性要求极高的领域，这一缺陷是完全不可接受的，可能引发重大风险和损失。
此外，MySQL 的可串行化/SR 隔离级别虽能避免这些问题，但实际生产中难以应用，也不是官方文档和社区推荐的最佳方案。即使开发者通过显式加锁解决，也会严重拖累性能，并且容易引发死锁。
此外，PostgreSQL 从 9.1 版本开始引入了可串行化快照隔离（SSI）算法，该算法能够以极低的性能开销实现完全的可串行化隔离级别。同时，PostgreSQL 的可串行化实现准确无误，甚至连 Oracle 都难以做到如此完美的正确性保障。

李海翔教授在一致性八仙图论文里，全面评估了主流数据库管理系统隔离级别的正确性。图中蓝绿色表示正确遵循规则或通过回滚避免异常；黄色A表示存在异常，数量越多正确性问题越突出；红色D表示采用死锁检测处理异常，红D越多性能影响越大。
显而易见，实现正确性最佳的是 PostgreSQL SR，其次是基于 PG 的 CockroachDB SR，二者表现相当。Oracle SR 存在轻微缺陷，但仍在可接受范围内。这些实现主要依靠机制和规则防止并发异常。相比之下，MySQL 表现堪忧，大量出现黄 A 和红 D，正确性及其实现方式都较为粗糙，难以令人满意。
做正确的事至关重要，正确性不应成为权衡利弊的因素。在这一点上，开源关系型数据库的两大巨头 MySQL 和 PostgreSQL 在早期开发时选择了截然不同的方向：MySQL 侧重性能优化，不惜牺牲一定程度的正确性；而 PostgreSQL 则坚持学术派的原则，优先保证正确性，即使这意味着性能会有所下降。
互联网发展初期，MySQL凭借性能优势崭露头角。然而，当性能不再关键，正确性反而成为其致命短板。更令人唏嘘的是，即使牺牲正确性换取的性能，如今也已失去竞争力，实在令人感慨。
一项技术的用户规模，直接影响其生态繁荣。即便衰退，家底仍在。MySQL 曾借互联网东风崛起，积累了庞大资本，其口号恰如其分——全球最受欢迎的开源关系型数据库。

2023年，根据全球权威开发者调查之一的StackOverflow Annual Developer Survey结果显示，MySQL的使用率已被PostgreSQL超越。曾经最受欢迎的数据库桂冠如今花落PostgreSQL，这一变化令人唏嘘。这标志着数据库领域格局的转变，PostgreSQL凭借其卓越性能和功能优势崭露头角，成为更多开发者的首选。
尤其值得关注的是，把过去七年的调查数据整合起来，就能得到专业开发者中 PostgreSQL 与 MySQL 使用率变化的趋势图（左上）。在相同的横向对比标准下，PostgreSQL 的崛起和 MySQL 的衰落表现得十分清晰。

对中国而言，这种此起彼伏的变化趋势同样存在。不过，若告诉中国开发者 PostgreSQL 已经超过 MySQL，显然与直觉和现实不符。
对 StackOverflow 上的专业开发者按国家分类后可以发现，在主要国家（样本数大于600的31国）中，中国 MySQL 的使用率最高，达58.2%，而 PostgreSQL (PG) 的使用率最低，仅为27.6%。这意味着中国的 MySQL 用户数量几乎是 PG 用户的两倍。
另一个极端是受到国际制裁的俄罗斯。PostgreSQL 成为其数据库的主力选择，使用率高达 60.5%，位列第一，几乎是 MySQL 使用率 27% 的两倍。这得益于 PostgreSQL 的开源特性，不受单一企业控制，为俄罗斯提供了稳定的技术支撑。
近年来，中国出于自主可控和信创的需求，PostgreSQL 的使用率显著提升。其用户规模已增长三倍，与 MySQL 的用户比例也从六七年前的 5:1，发展到三年前的 3:1，并迅速演变为如今的 2:1。可以预见，未来几年内，PostgreSQL 很可能追平甚至超越全球平均水平。毕竟，许多国产数据库都基于 PostgreSQL 开发，尤其在政企信创领域，PostgreSQL 已成为主流选择。如果你参与政企业务，大概率已经在使用它了。这一趋势表明，PostgreSQL 正在中国市场占据越来越重要的地位。
谁害死了MySQL？是PostgreSQL吗？Peter Zaitsev在Oracle最终杀死了MySQL中指责——Oracle的失职与错误管理导致了MySQL的衰落。后续文章Oracle还能拯救MySQL吗进一步揭示，根本原因在于Oracle对MySQL发展战略的忽视与资源投入不足，使这款开源数据库逐渐失去竞争力。这一问题值得深思。
Oracle 拥有 MySQL 的知识产权，它并非像 PostgreSQL 那样由社区拥有并管理，也没有 PostgreSQL 那样广泛的独立企业贡献生态。无论是 MySQL 还是其分支 MariaDB，都不是严格意义上的社区驱动型开源项目，无法与 Linux、PostgreSQL 或 Kubernetes 这类典型的纯正开源项目相提并论，而是主要由单一商业实体主导发展。这种模式决定了它们在社区参与度和去中心化特性上存在一定局限性。
与其给商业对手贡献代码，不如直接使用对方的代码来得更划算——AWS 和其他云服务商借助 MySQL 内核参与数据库市场竞争，却从未回馈过任何代码。作为竞争对手，Oracle 也因此不再用心维护 MySQL，而是转而投身云计算领域，专注于自家的 MySQL HeatWave 云服务，就像 AWS 只聚焦于 RDS 和 Aurora 一样。云厂商对 MySQL 社区的支持寥寥无几，因此社区逐渐衰退，云服务商也难逃责任。

过去的无法挽回，未来的仍可期待。PostgreSQL 应该从 MySQL 的兴衰中汲取教训——尽管 PostgreSQL 社区一直小心翼翼地避免出现单一主导力量，但其生态正逐渐向少数几家大型云厂商倾斜，这并非一个健康的发展方向。云正在改变开源的格局：云服务商开发了用于管理开源项目的软件，组建了专业团队，并通过提供维护和服务获取了项目生命周期中的绝大部分价值。然而，这些公司却将最大的成本——研发与生产任务转嫁给了整个开源社区，而自身并未充分回馈。更重要的是，那些真正有价值的管理和监控代码几乎从未开源共享。这种现象在数据库领域屡见不鲜，比如 MongoDB、ElasticSearch、Redis 和 MySQL 都曾遭遇类似问题。PostgreSQL 社区应对此保持警惕，以防止历史重演，从而保护自身生态系统的平衡与可持续发展。
幸运的是，PG 生态中从不缺乏坚定的人和企业，他们勇于站出来维护生态平衡，对抗公有云厂商的霸权。比如我开发的 PostgreSQL 发行版 Pigsty，它致力于提供一款即装即用、优先本地化的开源云数据库 RDS 替代方案，将社区自建的 PostgreSQL 数据库服务提升到与云厂商 RDS PG 相当的水准。此外，我的云计算泥石流系列专栏专注于揭示云服务背后的信息不对称问题，助力公有云厂商更体面地发展，效果显著。
我虽坚定支持 PostgreSQL，但也认同 Peter Zaitsev 的看法：如果 MySQL 完全消失，开源关系型数据库领域将被 PostgreSQL 垄断，而垄断会阻碍进步与创新。对 PostgreSQL 而言，有 MySQL 作为竞争对手并非坏事，反而能推动其不断完善和发展，进入更繁荣的状态。这种竞争关系有利于技术生态的健康发展，为用户带来更多选择与可能性。
至少，MySQL能成为一种激励，促使PostgreSQL社区保持团结和危机意识，不断提升技术能力，同时坚持开放、透明、公平的治理方式，以此不断推动数据库技术向前发展。
MySQL 曾经辉煌，是开源软件的标杆，然而再灿烂的篇章也有终章。MySQL 正逐渐衰落——更新乏力、功能落后、性能下降、质量下滑、生态萎缩，这似乎是不可避免的趋势。而 PostgreSQL 将秉承开源的初心与使命坚定前行，接续 MySQL 未完成的征程，书写其未能写就的壮丽诗篇，为数据库领域开辟新的篇章。
残梦飘零，九霄云外灵异现。
忙忙碌碌一场空，满心皆是愁绪
滑翔过后，优雅降落
于四维时空尽情穿梭遨游
我的拙作在各地流传。
云游魂飞，奏响愤音符吼
宿命面前，不断挥别过去。
视死如归，义无反顾，仇忾之心。
黑色的不是夜，是无尽的孤独感
脚下黑暗一片，头顶星光闪耀。
世间万物皆可期待，唯有真爱最为短暂。
失去不再来，守恒今朝倍偿。
热情渐逝，光阴远去，留下寂静无声。
人间悲喜如同烂剧，昼夜循环播放。
男女情感纠葛，爱恨情仇别离
岁月流逝人会老，青春永驻心不老。

Oracle是否还能挽救MySQL？
Oracle最终还是让MySQL消失了！
MySQL性能持续下降，Sakila数据库未来路在何方？
为什么MySQL的正确性表现得这么差？
PostgreSQL正在逐步主导数据库领域。
PostgreSQL 17 Beta1 发布，功能更新超丰富，不容错过！
为何说PostgreSQL将是未来数据的基石？

技术极简：一切皆依赖Postgres实现。
PostgreSQL：全球最受欢迎的开源数据库之一。
PostgreSQL究竟有多强大？
专用向量数据库是否已经不再热门？
向量成为全新的JSON
AI大模型结合PGVECTOR，实现高效矢量检索与分析。
云数据库面临的新模式与挑战
云端数据如泥石流
Redis不开源，既是开源之耻，也是公有云之耻。
PostgreSQL会更改其开源许可协议吗？