MySQL发展记事(202x)
2009-12-28 10:16:48 
阿炯
本文主要用于记录MySQL发展过程中的可为里程碑的事记，截止到2030年前。
甲骨文向MySQL用户、开发者和客户的十项承诺
MySQL被并购将开源数据库将倒退十年
四分五裂的MySQL能否重整山河
前MySQL CEO呼吁更多创业公司加入开源运动
后Sun时代MySQL出路何在
PostgreSQL创始人:MySQL衰退属必然
MySQL陷内忧外患或已处于消亡的边缘
Oracle最终还是杀死了MySQL
MySQL已死，PostgreSQL当立
甲骨文向MySQL用户、开发者和客户的十项承诺
甲骨文/SUN交易案最新动向：甲骨文向MySQL用户、开发者、客户做出十项承诺。
2009年12月下旬消息，甲骨文公司与欧盟委员会就甲骨文SUN公司的交易案进行了建设性的讨论，并承诺将保持MySQL在数据库市场的竞争力。为了进一步获得欧盟的批准，甲骨文公司公开其十项承诺，内容如下：
1、保证存储引擎API持续可用性
甲骨文保证并阶段性加强MySQL的可插拔存储引擎架构，让用户可以灵活选择从本地和第三方产品提供存储引擎。此保证意味着MySQL当前的使用政策有效，允许符合SUN文件的存储引擎供应商接入MySQL数据库。
2、不主张承诺
作为版权持有人，甲骨文将改变SUN的现行政策，同时不得声称或威胁任何人，存储引擎第三方供应商必须基于GPL发布的，因为他们已经实行了应用编程接口有效，作为MySQL的可插入式存储引擎架构的一部分。商业许可无需通过Oracle请求。甲骨文将复制此承诺到与SUN有商业许可关系的存储供应商的合同当中。
3、许可证的承诺
当他们目前MySQL的OEM协议终止后，甲骨文将提供这些存储供应商与SUN相同的许可条件，不超过2014年。甲骨文将复制此承诺到与SUN有商业许可关系的存储供应商的合同当中。
4、承诺在今后加强MySQL基于GPL发布
MySQL后续版本，包括版本6，均将通过GPL发布。甲骨文公司不会在没有发布社区加强版的同时发布一个新的企业加强版。甲骨文公司将继续把MySQL社区版的所有版本的源代码公开，将免费提供。
5、支持并不是强制性的
MySQL客户不会被要求从甲骨文获得支持服务作为购买商业许可的条件。
6、 增加对MySQL的研发支出
甲骨文承诺提供可用于MySQL持续发展的适当资金(GPL的版本和商业版本)。 在未来3年，每年，甲骨文将在MySQL的研发上投入比SUN的最近财年(2400万美元)还要多，在交易完成之前。
7、成立MySQL客户顾问委员会
不迟于6个月后的一周年之际，甲骨文将创建并资助一个客户咨询委员会，包括最终用户和嵌入式客户提供指导和反馈，作为MySQL的发展优先事项，以及其他MySQL客户的重要问题。
8、成立MySQL存储引擎供应商咨询委员会
不迟于6个月后的一周年之际，甲骨文将创建并资助一个存储引擎供应商咨询委员会，提供指导和反馈，作为MySQL的发展优先事项，以及其他MySQL存储引擎供应商的重要问题。
9、 MySQL参考手册
对MySQL参考手册，甲骨文公司将继续保持更新和免费下载，质量保持与SUN所提供的一致。
10、 客户支持服务将继续
甲骨文将确保付费的最终用户和嵌入式客户提供MySQL的支持服务，根据客户的喜好更新订阅。
这些承诺在全球范围内，并持续到交易完成五周年。
MySQL被并购将开源数据库将倒退十年
有自由软件之父之称的Richard Stallman在2009年10月下旬发表一封公开信给欧洲委员会的委员Neelie Kroes，请求不要让甲骨文(Oracle)合并MySQL。知识生态国际(KEI, Knowledge Ecology International)及开放权利组织(ORG, Open Rights Group)等两个非营利组织也加入联名。这份公开信并张贴在KEI网站上。
公开信指出，甲骨文买下MySQL是为了防止其数据库软件授权与服务的市场遭到侵蚀，以保护其专有的数据库软件的高额收费。如果Oracle成功合并MySQL，可预见的是，MySQL这个软件平台的功能与性能的发展都将受限，对于其使用者造成很重的伤害。
九月间EC宣布要深入调查甲骨文与SUN的合并案，特别是合并MySQL对数据库市场的影响，也因此MySQL的相关争议也陆续浮出台面。日前MySQL 作者兼联合创办人Michael 'Monty' Widenius除了表态支持欧盟对甲骨文的深入调查之外，并建议甲骨文卖掉MySQL以解除市场疑虑。
甲骨文是“旧”市场领导者 MySQL是未来市场“新”星
Stallman整份文件则不断强调甲骨文和MySQL之间的竞争关系，以及甲骨文对于MySQL未来的缺乏承诺及保障，以期望说服EC阻止甲骨文合并MySQL。
他指出，甲骨文是私有数据库软件的龙头厂商，其软件是为大型企业而设计，而且在这块市场里有霸主的地位，然后收取非常昂贵的费用，赚进大把的钞票。但在其他市场里，甲骨文面临许多数据库软件商竞争对手，包括私有软件的Microsoft SQL Server、Sybase，及IBM DB2；另外还有FLOSS(Free/Libre/ and Open Source)平台，特别是MySQL。
从1998年开始，开源的网页服务器软件就有LAMP。LAMP也是Linux操作系统，Apache HTTP服务器软件，MySQL数据库，以及PHP网页描述语言的简称。这些软件被用来打造数以百万及的网络应用，根据升阳的数字，MySQL的下载量每天超过6.5万次。一般而言，使用者可以透过两种方式取得MySQL，大多数都是在GNU的通用公共授权(GPL)第二版的条款下自由而免费取得；另外也可以专属软件的付费授权方式取得。
随着时间的演进，MySQL在功能，稳定性，以及性能上不断改进，而且已经成为数据库市场中占有重要的地位，并受到开源社区的信赖──其重要性远非市场营收占有率可以衡量分析得出来的，Stallman表示。
MySQL对于私有软件的价格也带来重要的市场压力，让甲骨文及微软等业者的授权费趋于合理或更低，甚至也有许多企业在转向采用MySQL数据库。“如果甲骨文是今日旧据库市场的统治者，那么MySQL就是‘新’的新兴数据库市场的主导者，因此MySQL可以视为甲骨文未来的最重要竞争对手。”Stallman说。
开源数据库将会倒退数年
事实上甲骨文曾在2006年时就要买MySQL，但由于无法揭露它对MySQL未来的发展计划而遭拒，当时MySQL的管理者甚至担心，甲骨文此举只是想要防止MySQL的市场发展。
Stallman认为，相较之下SUN买下MySQL之所以让各界所接受，是因为它过去一向以倡导开放源码而广受好评，同时一般认为Sun能够给MySQL很好的市场定位。虽然被Sun买了之后有不小的人事变动，但大体来说，核心的软件产品仍有持续的扩大与改进。另一方面，MySQL作者 Widenius之前的公开信也指出：“SUN是MySQL最好的归宿。”
至于外界看法认为，甲骨文无法伤害MySQL，因为在GNU GPS v2.0管辖下，如果甲骨文未能开发程序代码，任何的其他企业或个人都可以接手MySQL未来的开发；另一看法认为，甲骨文是要以MySQL强化与微软 SQL Server的竞争。Richard Stallman都一一加以反驳。
他指出，MySQL使用平行授权的方式，可以透过收费授权所带进的营收来养FLOSS软件的开发。然而，一但MySQL被甲骨文所合并，甲骨文不只没有义务积极推销MySQL或以合理价格提供其商业授权；更没义务拿这些营收来改进MySQL。而且在相关决策上，甲骨文显然有利益冲突问题，恐怕会以保护其收费的数据库为优先。
Stallman表示，对于FLOSS数据库平台来说，MySQL被甲骨文合并将是一种倒退，可能瓦解MySQL的核心开发者社群。而要产生另一个足以与MySQL相提并论的数据库平台，恐怕还需要很多年的时间。
四分五裂的MySQL能否重整山河
在Oracle宣布收购Sun一个月之后的2009年9月下旬，MySQL的未来仍悬而未决，51CTO.com曾报道过业界对收购后MySQL前景的担忧。在领先的商业数据库供应商手中，MySQL这个领先的轻量级开源数据库还能够继续保持兴旺吗？到目前为止，形势好像并不乐观。
早在Oracle收购之前，MySQL社区就有了紧张的迹象。2008年在Sun收购MySQL后不久，许多重要的MySQL员工就开始陆续离开，其中包括 CEO Mårten Mickos和共同创始人Monty Widenius。Widenius更是公开抨击了由Sun领导的MySQL开发流程，批评发布周期太过匆忙以及缺乏质量控制。另一位共同创始人 David Axmark也在受够了Sun陈旧的企业文化和繁杂的办事方式后选择了离开。在51CTO.com之前关于MySQL两位创世人离职对Sun的影响一文中曾猜测Sun领导下的MySQL是否会更好？现在，该换Oracle领导的MySQL是否会更好了。
随着骨干成员大批出走，MySQL的发展碰到 了另一个难关：MySQL的分支开始出现，包括Drizzle和MariaDB，它们向用户和贡献者提供 Sun控制的主要分支之外的方式。Drizzle试图摆脱一些最近的MySQL版本中过多的功能，为云计算和Web应用服务器提供更合适的轻量级数据库。而MariaDB目标是与MySQL功能兼容，而且默认使用全新的transaction-capable存储引擎。可能更重要的是，MariaDB 的创建者不是别人，正是MySQL的开山鼻祖Widenius本人。
如果这些事还不能让MySQL的新东家Oracle头疼的 话，Widenius已经扔出了另一波攻势。上周，51CTO.com曾在5月13日报道过 Widenius宣布成立开放数据库联盟(Open Database Alliance)的消息，一个“供应商中立的组织”，他们的目标是要“成为MySQL开源数据库的业界枢纽，包括MySQL和衍生代码、二进制文件、培训、支持和MySQL社区和合作伙伴系统的改进。”值得注意的是，Oracle没有被列入开放数据库联盟的联系人名单。
对这一切感到为难的人绝不会少。今年3月，前MySQL员工，现在的Drizzle开发者Patrick Galbraith曾大声质疑现在哪个MySQL分支才能算得上“官方正式版”。这个问题的最终答案或许就是MySQL的命运。
Oracle能够重视MySQL吗？
当然，名义上MySQL只可能有一个真正的官方正式版：就是那个最初的MySQL，后来被Sun收购，并最终被Oracle获得的那个。Oracle目前拥有与MySQL的名字相关的所有版权，商标和其他知识产权——它在保护知识产权时一向不遗余力。MySQL甚至曾经向一些合作伙伴发出商标违反通知，只因为他们在其提供的服务中标注的是“MySQL support(MySQL支持)”，而不是“支持MYSQL数据库(support for MySQL databases)”。
虽然这方面做的不错，但是MySQL的品牌本身并不会让顾客感到舒心，他们担心一个开源数据库不会得到世界上最大的商业软件公司的应有重视。已经有一些客户质疑Oracle对MySQL的承诺，尤其是当它拥有利润丰厚的商业数据库时，对低端的开源产品的态度究竟会怎样。MySQL社区已经开始分裂并各自转向替代品，Oracle的MySQL的业务正逐渐变得缺乏吸引力。
但是，如果MySQL的支持率正在下降，Oracle更应该快点做出决断。Oracle必须努力恢复MySQL社区的信任和支持，否则就可能眼睁睁的看着它变成一把叉子——长出 Drizzle、MariaDB或者其它分支。为了做到这一点，Oracle必须要避免Sun在收购MySQL时犯的错误。从某种意义上说，想要 MySQL成功，Oracle要表现得不像Oracle一点。
开源项目的客户是出了名的挑剔。如果一个项目不能提供用户需要，用户可以立刻去找其他的——开发者也一样。有许多开源项目都出现了叉子的状况，也有观点认为这样的竞争是健康的。而对于Oracle来说，最好希望自己不要走错了路口。
如果MySQL变成叉子，谁会输，谁会赢？
巧合的是，在开源世界的另一个领地正在上演类似的情节。这个主角是glibc——Gnu standard C library(GNU标准C库)——Linux上运行的几乎所有软件都在用它。本月初，Debian项目决定用eglibc(Embedded glibc)，也就是glibc的一个分支来替换掉它。表面上看新的分支可以更好地为嵌入式系统编程服务，但社区里却可以听到些闲话说替换glibc的真正原因在于glibc主要维护者Ulrich Drepper的顽固不化。
eglibc的出现肯定不是偶然的。它与很久以前的一次争议事件遥相呼应，当时有一群从事Gnu C compiler(GCC，Gnu C编译器)的开发者由于受不了项目贡献模式的严格限制，分离出去形成了一个称为egcs的新分支。摆脱了官僚主义之后，egcs分支繁荣发展，而gcc的 主分支依旧停滞不前，最后以gcc的死去而其后egcs正式改名为gcc而告终，分支最终变成了主干。根据一些egcs开发者所说，他们从一开始就有这样 的打算。很难讲这次eglibc的维护者们是不是也有类似的想法。
Oracle和其他开源项目的维护者都应该在这里好好的上一课。缓慢的专制管理是许多开源软件的用户和贡献者所不愿意容忍的，而被企业等商业实体维护的项目特别容易受到这种影响。在Eric S. Raymond发表了他那篇论文大作“大教堂和集市”的12年之后，我们看到仍有太多的项目——尤其是企业——还是无法放掉自己的大教堂心态。
因此Oracle最好的行动方针应该是立即加入开放数据库联盟，并以积极的态度参与MySQL的开发，而且要全力保护由社区推动的开放的方式。Oracle将MySQL作为Sun的一项资产买下来，但是Sun一直没有抓住MySQL的重点，也不知道如何管理。如果Oracle想不出怎样比Sun 做的更好，那么它仍将拥有MySQL的名号，然而不幸的是，这个名号很快就会没有多大意义了。
前MySQL CEO呼吁更多创业公司加入开源运动
据国外媒体报道，MySQL前CEO马顿·米克斯（Marten Mickos）于2010年3月下旬在EclipseCon 2010会议上强调，开源已不再是失败者，但需要有更多创业公司通过开源软件赚钱。
软件业专家在EclipseCon公司举办的会议上讨论了开源的未来。米克斯强调，通过开源赚大把钞票的创业公司太少。倒是拥有成熟商业模式的 IBM、微软、甲骨文和Apache Software、Eclipse、Linux和Mozilla基金会等公司为开源发展不懈努力。米克斯说：“我们希望有非常棒的创业公司通过开源赚上数百万、甚至数十亿美元，但目前还没有实现这一目标。开源领域有大量成功的赚钱公司如红帽、 JBoss、MySQL及XenSource，但光有这些还远远不够。”
米克斯最近出任开源云技术创业公司Eucalyptus的CEO。MySQL于2008年被Sun收购，甲骨文今年1月完成对Sun的收购后，获得 MySQL。米克斯说：“MySQL能够为开源运动贡献大量GPL代码，因为该领域一直有营收。”米克斯称，有部分人士批评MySQL的双重许可计划，即 公司一方面通过开源提供软件，同时向要求提供支持服务的用户收费。
Apache Software基金会总裁贾斯汀·伊伦科朗茨（Justin Erenkrantz）也强调有必要保证开源营收。伊伦科朗茨说：“需要维持商业公司赚钱的生态系统，便于开发人员为开源做贡献的同时能获得一份收入，这 就需要开源社区和创业公司共同保证开源的未来。”
开源分析与咨询公司RedMonk分析师斯蒂芬·奥格雷迪（Stephen O'Grady）对开源未来表达了不同的观点，强调分散化的开发和基础设施。奥格雷迪还强调通过对信息进行聚合、分析，挖掘数据潜力。尽管有部分观点认定开源无法创新，只是使市场商品化，但奥格雷迪指出，开源已在云技术领域引发了创新。他同时承认，开源也是市场商品化的积极推进者。
后Sun时代MySQL出路何在
Oracle对于Sun的合并过程已经完成。2010年4月中旬，欧盟委员会也已经对该合并表示了祝福。Oracle的标识已经骄傲地显示给任何在浏览器中输入 “sun.com”的人。因此如果你访问mysql.com网站，几乎看不到任何人提到Sun(Sun在2008年用10亿美元收购了MySQL)，而在这个网页的最底下一行印着大红的Oracle标识。
看起来好像那些无休止的诉讼案情摘要、听证会、唇枪舌剑等等所有事情都不曾发生过一样。现在，全球各地的数据库管理员、IT经理和小型网站运营商继续像往常一样工作，MySQL继续在服务器上运行并回应着数据库查询。但是现在，是Oracle拥有了MySQL的版权。所以，这个问题依然存在：MySQl这个流行的开源软件数据库的未来会怎样？众多依赖于它的机构的未来会怎样？
这是一个棘手的问题。这个问题的答案主要取决于MySQL在你的企业中发挥的作用、你使用的许可证类型、你想花的钱的总数、你要采购什么以及你在未来要与谁合作等等。使这个事情更加复杂的是，MySQL是世界上最著名的开源软件项目和业务之一，因此，任何有关MySQL的讨论都会变成一场有关开源软件许可证的争论，例如GPL许可证。
MySQL的今天和明天
对于MySQL爱好者的好消息是：它不会很快就无人管理而枯萎和死亡。Oracle已经公开保证它将比Sun投入更多的资金开发这个数据库，至少在未来三年之内是如此。MySQL的社区版将继续得到改善。该版本是根据GPL许可证发布的，所有的源代码都是免费的。
这些保证表明，普通的MySQL用户不需要考虑在未来几年里是否放弃MySQL的问题。如果你对于所使用的数据库的版本满意，只要你有一个编译器，就能够一直保持它运行。
有一些充分的历史证据表明，Oracle将让用户更轻松地继续使用MySQL，而不再需要编译器。一位很熟悉Oracle在收购开源软件数据库公司 Sleepycat之后如何使其成熟的开发人员说，这次收购对于所有人都是非常不错的。现在Sleepycat的工程师人数比以前多多了，而且并未改变过该数据库的许可证。
一位不愿透露姓名的Oracle开发人员说，“4年之后，我们大家都还在这里。人人仍在工作并且很快乐。Oracle是很不错的工程师之家。”
当然，这种保证还不足以安抚每一个人紧张的神经。MySQL网站显著地有别于Sleepycat.com(后者并重定向至Oracle网站)的事实也许不仅仅是一个疏忽。Oracle管理层很清楚人们对于MySQL的未来之路充满了混乱之感，所以把mysql.com网站重定向到oracle.com网站，只会让那些在Sun被收购之后仍然感到担心的人们更加不安。
你的许可证还是我的许可证？
机构和开发人员并非只是简单地担心MySQL作为一种产品的未来，而是担心Oracle拥有该数据库及其许可证的方式是否会影响到许可证的授权。
MySQL的创始人之一Monty Widenius也是公开反对Sun与Oracle合并的人士之一。他在2009年离开了Sun去了MariaDB，这是在Monty Program AB公司之下开发的一种新版本的MySQL源代码。
Widenius一直在游说欧盟委员会阻止Oracle与Sun的合并。他争辩说，允许Oracle控制MySQL版权对于欧洲和整个社会来说都不是好事。他的理由是，像MySQL那样，产品建立在开源软件数据库基础上的公司，只能够向不愿受GPL许可证束缚的用户提供商用许可证才能持续生存下去。
因此，他争辩说，如果Oracle成为单独的版权拥有者，就不会允许任何竞争者销售商用许可证。(原先MySQL公司也一直坚持保留全面的版权，要求所有的作者签署协议把版权授予该公司。这项权利就意味着他们且只有他们能够出售商用许可证，而不必理会GPL协议。)
迫使用户采用GPL许可证的麻烦其实并不在于这个有争议的许可证本身，而在于这件事情的细节会变得更加复杂。比如说，有些人认为，该许可证可适用于和所有软件密切相关的驱动程序和连接协议。而其他人则认为，这种想法过于大言不惭了。
在过去，MySQL的销售人员会很有效地利用潜在客户对于GPL许可证的混乱想法，设法说服他们相信，选择一个商用许可证会更简单，可以消除未来可能出 现的任何代价昂贵的法律纠纷。当然，出售商用许可证可以喂饱饥饿的开发人员的肚子。这种销售方法已经证明是一个有效的和有利可图的吓唬人的策略。
PostgreSQL创始人:MySQL衰退属必然
MySQL被称为是最受欢迎的开源数据库，如今它的前途因为Oracle与Sun并购交易存在不确定性而变得扑朔迷离，可能会导致大量用户流失。PostgreSQL创始人之一的Bruce Momjian在2009年12月中旬接受IT168记者采访时表示“MySQL衰退，这并不是一件很令人惊奇的事情。”Bruce Momjian认为MySQL衰退缘自2个方面的原因，其一，MySQL定位不明晰，其二MySQL不是一个纯粹的开源数据库。
Bruce Momjian进一步解释：“之所以说MySQL定位不明晰，是因为其初始目标定位在网络应用的用户层面上，而互联网企业要求的是一个快速反应时间和较小的用户量，但相对大用户来说，MySQL就有点捉襟见肘了。虽然MySQL非常努力去试图满足大客户的应用，想扩展企业级应用标准，但因为前期开发的框架不是很明晰，导致不是很成功，结果是我们看到的先是被Sun收购，又被Oracle并购。”
作为一个小型关系型数据库管理系统，MySQL的开发者为瑞典MySQL AB公司，并在2008年1月16日被Sun微系统公司以10亿美元的价格收购。
Bruce Momjian认为：“MySQL数据库是一个公司的一产品，是一个公司做了绝大部分开发的工作，所以MySQL不是完全意义上的开源数据库，这是个劣势，不能得到绝大多数人的支持，或让社区更多人参与进来。”
IDC的数据显示，2008年MySQL营收为4000万美元,市场份额为0.2%。MySQL每天下载量约为6万次,是当前应用最广泛的开源数据库，按照欧盟委员会的说法，其实际竞争力远高于按市场份额计算应有的水平。同时欧盟委员会还表示担忧：甲骨文收购开源软件数据库软件MySQL可能会消除重要的竞争对手和提高这种软件的价格。尽管Oracle承诺会保持MySQL的独立性，众多反对者还是担心，如果MySQL被最大的私有数据库厂商 Oracle收归麾下，可能遭到Oracle的抛弃甚至打压。
选择pgsql还是mysql
mysql出现在1994年，现在所有权归属oracle，创始人现在又发布了新的免费开源数据库MariaDB，现在开源关系型数据库领域，mysql使用确实是最广泛的，官方说许多世界上最大、发展最快的组织都在使用mysql。
pgsql又称PostgresSQL，出现在1986年，官方标榜自己是世界上最先进最高级的开源关系型数据库。
pgsql和mysql简介：
pgsql的一方面可以跟oracle相媲美，可靠性是pgsql的最高优先级，数据一致性与完整性也是pgsql的高优先级特性；
mysql和pgsql都出现在一些高流量的web站点上，都能用在大型分布式系统上，都支持事务，都支持全文索引；
mysql现在已经支持嵌入式应用，而pgsql依然坚守在传统B/S架构上；
mysql能够进行快速地读取和大量的查询操作，不过在复杂特性与数据完整性检查方面不太尽如人意；
pgsql是针对事务性企业级应用严肃、功能完善的数据库，支持强ACID特性，会做很多数据完整性检查；
mysql上myISAM存储引擎因为执行很少的数据完整性检查，所以速度快，对于敏感数据，对读写要求高的数据，支持ACID特性的InnoDB则是个更好的选择，相反pgsql是个只有单一存储引擎完全集成的数据库；
mysql与pgsql都是高可配置的，通过参数调整性能，也可以调整查询与事务特性，他们都支持通过扩展添加额外的功能；
pgsql可靠性更好，稳定性很强，在保护数据安全方面更擅长，并且是社区项目，不会陷入商业厂商牢笼之中；
mysql的普及更广一些，学习资料更多，熟练使用的人更多，所以选择mysql的企业很多。
pgsql相比mysql的优势：
pgsql存储过程的功能支持要比mysql好，具备本地缓存执行计划的能力；
pgsql对表连接支持更完整，优化器的功能更完整，支持的索引类型很多，复杂查询能力较强；
pgsql主备复制属于物理复制，支持异步、同步、半同步复制，mysql基于binlog的逻辑复制，是异步复制，pgsql数据的一致性更加可靠，复制性能更高，对主机性能的影响也更小；
pgsql支持json数据类型，而mysql不支持，mysql字符型有长度限制，而pgsql的text类型无限长，可以使用xml xpath，用pgsql的话，mongodb这样文档数据库就省了；
pgsql是完全免费开源的，而mysql归属oracle后，开源程度大不如以前；
pgsql在GIS领域多年来处于优势地位，有丰富的几何类型，支持极其丰富的空间函数，可以建立R树、GIST树等空间索引，instagram就是因为pgsql的空间数据库扩展postgis远远强于mysql的my spatial而采用的pgsql；
pgsql有极其强悍的sql编程能力，有非常丰富的统计函数和统计语法支持，可用多种语言写存储过程，对R支持也非常好，这一点mysql就差的很远，腾讯内部数据存储主要用mysql，但是数据分析主要是hadoop+pgsql；
pgsql有多种集群架构可选择，plproxy可以支持语句级的镜像或分片，slony可以进行字段级的同步设置，standby可以构建WAL文件级或流式的读写分离集群，同步频率和集群策略调整方便，操作非常简单；
pgsql支持topology、pgrouting等功能强大、方便使用的GIS扩展，例如可以用pgrouting计算路径规划；
pgsql数据库方便QGIS等GIS工具连接和图层展示等操作；
mysql相比pgsql的优势：
mysql采用索引组织表，这种存储方式非常适合基于主键匹配的查询、删改操作，但是对表结构设计存在约束；
mysql的优化器较简单，系统表、运算符、数据类型的实现都很精简，非常适合简单的查询操作；
mysql分区表的实现要优于pgsql的基于继承表的分区实现，主要体现在分区个数达到上千上万后的处理性能差异较大；
mysql的存储引擎插件化机制，使得它的应用场景更加广泛，比如除了Innodb适合事务处理场景外，Myisam适合静态数据的查询场景；
mysql也支持空间索引，是用R树实现的空间索引，但空间函数等功能不如pgsql丰富，空间查询比pgsql慢；
pgsql更适合严格的企业应用场景，比如金融、电信、ERP、CRM等，mysql更适用业务逻辑相对简单、数据可靠性要求更低的互联网场景，比如google、facebook、淘宝等。
下图是redis、mongo、pgsql、mysql在一个空间查询场景下的性能对比：
pgsql支持的几种高级插件：
postgis提供丰富的空间数据类型和空间函数。
pgrouting 用来进行路径规划。
postgis_topology 用于管理点、线、面等拓扑对象。
postgis_sfcgal 用于实现3D相关算法。
fuzzystrmatch 字符串相似度计算。
address_standardizer 用于地址标准化。
pg_trgm 用于分词索引。
结论：
如果空间操作比较多，比较复杂，那就得选择pgsql；
如果对数据安全性和稳定性要求很高，pgsql是更好的选择；
如果业务场景没那么复杂，mysql完全可以胜任。
MySQL陷内忧外患或已处于消亡的边缘
甲骨文为了在收购Sun交易中获得MySQL费尽心思，才最终获得监管机构的批准，目前来看这些努力可能是在浪费时间和金钱，人们或将突然发现：内忧外患的MySQL已经处于消亡的边缘。
在2010年4月举行的MySQL大会上，MySQL之父迈克尔.韦德纽斯(Michael Widenius)和大名鼎鼎的MySQL架构师布莱恩.阿克尔(Brian Aker)分别发表演讲，他们坚信任何一家公司都不可能成为MySQL开发或支持服务的唯一提供商。这些MySQL名人的做法对甲骨文来说是一种考验，将验证甲骨文与MySQL社区配合和容忍不同意见的程度。
2010年5月，旧金山新创公司Clustrix公开宣称，自己的产品更强大更优秀，可以完成MySQL做不好的事情，可扩展至存储数十亿条数据，完全可以取代MySQL。Clustrix产品中不存在MySQL的 DNA，但它可以与MySQL协议互通，这样应用程序再也无需进行代码移植，它的存在无疑会伤害MySQL的付费业务。
该产品被称为针对互联网规模级应用程序的首款集群数据库系统，据说它遵循了应用程序服务器和存储系统突变成可扩展式、群集产品的进化路线。它具有NoSQL的key/value存储的巨大可扩容能力和高性能，而且封装在3节点服务器CLX 4010设备内的SQL具有可靠的ACID测试相关功能，该硬件设备足以处理高负荷的读/写数据操作。
这三个或更多机架式设备都需要运行一个被称为Sierra集群数据库引擎的软件。据Clustrix称，用户希望或需要多大的可扩展性，取决于把多少节点设备加入到机架中。Sierra群集数据库引擎是一个非共享式执行环境，包含Sierra并行规划器(Parallel Planner)和Sierra分布式执行引擎(Distributed Execution Engine)。它把查询任务提供给分布式数据，而不是像RDBMS那样把数据提供给查询任务。
这意味着Clustrix群集数据库应该能够以最大的并行性执行查询语句，许多同步查询具有最大的并发性。这将带来极高的可扩展性、读/写操作性能、可用 性、在线调整纲要、自我修复和自我管理。
Clustrix团队从Isilon Systems那儿学到不少经验，后者层针对存储系统开发过类似的高并行和分布式产品。Clustrix已经从风险投资机构那儿获得了1800万美元来研 发可扩展数据库。
Clustrix群集数据库的目标用户群是面向事务处理的云计算服务提供商、企业和社交网站类互联网公司，它们在处理互联网生活中令人难以置信的繁琐数据 时，为了获取所需的扩展性，不得不忍受在应用程序层不断进行合库和拆库的操作。同样在解决该问题的还有开源项目 Hadoop和Cassandra，以及谷歌的BigTable。
要想扩容MySQL数据库，通常需要许多令人痛苦的定制化编程，这是一个成本高且耗时的工作，而且在单实例数据库中很难找到互联网规模的关系数据库功能。
Clustrix承诺，借助于它的产品，人们不再需要这类代码编写工作。Clustrix的群集数据库系统能够以增量和无缝方式扩容至数百个节点，运行时就像一个单一实例数据库一样，具有全部关系数据库功能和一致的即时事务处 理。
该工具可以被透明和不中断的部署到分片、非分片和复制MySQL环境中。当客户需要增加更多的CLX 4010节点时，这个分布式和并行体系架构可以自动发布数据到新的节点，即使在写数据负荷非常重的情况下，也能实现线性提高性能。它通过自动负载均衡、失效切换、还原和自我修复实现高可用性。
Clustrix双核及四核设备包含两个1Gbps以太网口和两个20Gbps的 InfiniBand背板端口，同时还装配32GB RAM和7个160GB固态硬盘。三节点设备的报价是109995美元。其表示之前它已经开始销售这些产品，并且在今年第一季度达成第一笔交易。据称该公司目前已经收到不少订单，很明显对某些MySQL客户来说，他们的产品比较有吸引力。
Oracle最终还是杀死了MySQL？
2024年6月消息，2008年，Oracle收购了Sun公司，从而也拥有了MySQL，互联网上关于Oracle何时会“扼杀MySQL”的讨论此起彼伏。
当时流传着各种理论：从彻底扼杀 MySQL 以减少对 Oracle 专有数据库的竞争，到干掉 MySQL 开源项目，只留下 “MySQL企业版” 作为唯一选择。这些谣言的传播对 MariaDB，PostgreSQL 以及其他小众竞争者来说都是好生意，因此这些谣言在当时传播得非常广泛。然而实际上，Oracle 最终把 MySQL 管理得还不错。MySQL 团队基本都保留下来了，由 MySQL 老司机 Tomas Ulin 掌舵。MySQL 也变得更稳定、更安全。许多技术债务也解决了，许多现代开发者想要的功能也有了，例如 JSON支持和高级 SQL 标准功能的支持。
虽然有 “MySQL企业版”，它实际上关注的是开发者不太在乎的企业需求：如可插拔认证、审计、防火墙等。虽然也有专有的 GUI 图形界面、监控与备份工具（例如 MySQL 企业监控），但同样有许多开源和商业软件竞争者，因此并没有产生特别大的供应商锁定效应。在这段时间里，有人也常为 Oracle 辩护，因为许多人都觉得 MySQL 会遭受虐待，就因为 —— 它是Oracle。在那段期间，Oracle 一致遵守了这个众所周知的开源成功的黄金定律：“转换永远不应该妨碍采用。”
注：“Conversion should never compromise Adoption” 这句话指在开发或改进开源软件时，转换或升级过程中的任何变动都不应妨碍现有用户的使用习惯或新用户的加入。
然而近些年来，随着 Oracle 推出了 “MySQL Heatwave”（一种 MySQL 云数据库服务），事情开始起变化了； 其引入了许多 MySQL 社区版或企业版中没有的功能，例如加速分析查询与机器学习。在“分析查询”上，MySQL 的问题相当严重，到现在甚至都不支持并行查询。市场上新出来的 CPU 核数越来越多，都到几百个了，但单核性能并没有显著增长，而这严重制约了 MySQL 的分析性能提升 —— 不仅仅是分析应用的查询受限，像日常应用里简单的 GROUP BY 查询也会受影响。（备注：MySQL 8 对 DDL 有一些 并行支持，但查询没有这种支持）
这么搞的原因，是不是希望用户能够有更多理由去买 MySQL Heatwave？但或者，人们其实也可以直接选择用分析能力更强的 PostgreSQL 和 ClickHouse。
另一个开源 MySQL 较弱的领域是向量检索。其他主流开源数据库都已经添加了向量检索功能，MariaDB 也正在努力实现这个功能，但就目前而言，MySQL 生态里只有云上限定的 MySQL Heatwave 才有这个功能，这实在在是令人遗憾。
然后是最奇怪的决策 —— Javascript 支持是一个只在企业版中提供的功能，主流观点认为 MySQL 应该竭尽所能地去赢得 Javascript 开发者的心，而现在很多 JS 开发者都更倾向于更简单的 MongoDB 了。
上述举措都违背了前面提到的开源黄金法则 —— 因为它们显然限制了 MySQL 的采用 —— 不论是这些“XX限定”的特定功能，还是对 MySQL 未来政策变化的担忧。
如果这还不够，MySQL 的性能也出现了严重下降，似乎是因为多年来对性能工程部门的忽视。与MySQL 5.6 相比，单线程简单工作负载上的性能出现了大幅下滑。你可能会说增加功能难免影响性能，但 MariaDB 的性能退化要轻微得多，而 PostgreSQL 甚至能在 新增功能的同时显著提升性能。
显然无法窥视甲骨文管理团队的讨论，也不能说这到底是蠢还是坏，但过去几年的这些产品决策，显然不利于MySQL的普及，特别是在同一时间，PostgreSQL 在引领用户心智上大步向前，在 DB-Engines 排名上大幅缩小了与 MySQL 的热度差距，而根据 2023 StackOverflow 开发者调查，甚至已经超过 MySQL 成为最流行的数据库了。
无论如何，除非甲骨文转变其关注点，顾及现代开发者对关系数据库的需求，否则 MySQL 将坐以待毙 —— 无论是被 Oracle 的行为杀死，还是被 Oracle 的不作为杀死。
原文：Percona Blog，作者 Peter Zaitsev。Percona 是 MySQL 生态的重要贡献者，开发了知名的PT系列工具，MySQL备份工具，监控工具与发行版。
译者：冯若航，网名 Vonng，Pigsty 作者，PostgreSQL 专家与布道师。数据库老司机，云计算泥石流。
MySQL已死，PostgreSQL当立
2024年7月MySQL v9.0 终于发布了，距离上一次大版本更新 8.0 (2016-09) 已经过去整整八年。然而这个空洞无物的所谓 “创新版本” 却犹如一个恶劣的玩笑，宣告着 MySQL 正在死去。
空洞无物的创新版本
糊弄了事的向量类型
姗姗来迟的JS函数
日渐落后的功能特性
越新越差的性能表现
无可救药的隔离等级
枯萎收缩的生态规模
是谁杀死了MySQL?
PG驶向云外，MySQL安魂九霄
PostgreSQL 正在高歌猛进，而 MySQL 却日薄西山，作为 MySQL 生态主要抗旗者的 Percona 也不得不悲痛地承认这一现实，连发了三篇《》，《》，《》，公开表达了对 MySQL 的失望与沮丧；Percona 的 CEO Peter Zaitsev 也直言不讳道：有了 PostgreSQL，谁还需要 MySQL 呢？—— 但如果 MySQL 死了，PostgreSQL 就真的垄断数据库世界了，所以 MySQL 至少还可以作为 PostgreSQL 的磨刀石，让 PG 进入全盛状态。
有的数据库正在吞噬数据库世界，而有的数据库正在黯然地凋零死去。
MySQL is dead，Long live PostgreSQL！
空洞无物的创新版本
MySQL 官网发布的"What's New in MySQL 9.0"介绍了 9.0 版本引入的几个新特性，而一文对此做了扼要的总结：
然后呢？就这些吗？这就没了！？
这确实是让人惊诧不已，因为 PostgreSQL 每年的大版本发布都有无数的新功能特性，例如计划今秋发布的还只是 beta1，就已然有着蔚为壮观的新增特性列表：
而最近几年的 PostgreSQL 新增特性甚至足够专门编成一本书了。比如《》便收录了 PostgreSQL 最近七年的重要新特性 —— 将目录塞的满满当当：
回头再来看看 MySQL 9 更新的六个特性，后四个都属于无关痛痒，一笔带过的小修补，拿出来讲都嫌丢人。而前两个向量数据类型和JS存储过程才算是重磅亮点。
BUT ——
MySQL 9.0 的向量数据类型只是BLOB类型换皮 —— 只加了个数组长度函数，而这种程度的功能，28年前PostgreSQL 诞生的时候就支持了。而 Javascript 存储过程支持竟然还是一个企业版独占特性，开源版不提供 —— 同样的功能，13年前的 PostgreSQL 9.1 就已经有了。
时隔八年的 “创新大版本” 更新就带来了俩“老特性”，其中一个还是企业版特供。“创新”这俩字，在这里显得如此辣眼与讽刺。
糊弄了事的向量类型
2023年，AI爆火，带动了向量数据库赛道。当下几乎所有主流 DBMS 都已经提供向量数据类型支持 ——MySQL 除外。用户可能原本期待着在 9.0 创新版，向量支持能弥补一些缺憾，结果发布后等到的只有震撼 ——竟然还可以这么糊弄？
在 MySQL 9.0 的官方文档上，只有三个关于向量类型的函数。抛开与字符串互转的两个，真正的功能函数就一个VECTOR_DIM：返回向量的维度！（计算数组长度）
向量数据库的门槛不是一般的低 —— 有个向量距离度量函数就行（内积，10行C代码，小学生水平编程任务），这样可以通过全表扫描求距离 +ORDER BY d LIMIT n实现向量检索，至少是个可用的状态。
但 MySQL 9 甚至连这样一个最基本的向量距离函数都懒得去实现，这绝对不是能力问题，而是 Oracle 根本就不想好好做 MySQL 了。老司机一眼就能看出这里的所谓 “向量类型” 不过是BLOB的别名 —— 它只管你写入二进制数据，压根不管用户怎么查找使用。最后交付个十分钟就能写完的东西糊弄了事。
不糊弄的例子可以参考 MySQL 的老对手 PostgreSQL。在过去一年中，PG 生态里就涌现出了至少六款向量数据库扩展（pgvector，pgvector.rs，pg_embedding，latern，pase，pgvectorscale），并在你追我赶的赛马中卷出了新高度。最后的胜出者是 2021 年就出来的pgvector，它在无数开发者、厂商、用户的共同努力下，站在 PostgreSQL 的肩膀上，很快便达到了许多专业向量数据库都无法企及的高度，甚至可以说凭借一己之力，干死了这个数据库细分领域。
在这一年内，pgvector性能翻了 150 倍，功能上更是有了翻天覆地的变化 ——pgvector提供了 float向量，半精度向量，bit向量，稀疏向量几种数据类型；提供了L1距离，L2距离，内积距离，汉明距离，Jaccard距离度量函数；提供了各种向量、标量计算函数与运算符；支持 IVFFLAT，HNSW 两种专用向量索引算法（扩展的扩展 pgvectorscale 还提供了 DiskANN 索引）；支持了并行索引构建，向量量化处理，稀疏向量处理，子向量索引，混合检索，可以使用 SIMD 指令加速。这些丰富的功能，加上开源免费的协议，以及整个 PG 生态的合力与协同效应 —— 让pgvector大获成功，并与 PostgreSQL 一起，成为无数 AI 项目使用的默认（向量）数据库。
拿pgvector与来比似乎不太合适，因为 MySQL 9 所谓的“向量”，甚至都远远不如 1996 年 PG 诞生时自带的“多维数组类型” —— “至少它还有一大把数组函数，而不是只能求个数组长度”。然而向量数据库的宴席都已经散场了，MySQL 都还没来得及上桌 —— 它完美错过了下一个十年 AI 时代的增长动能，正如它在上一个十年里错过互联网时代的JSON文档数据库一样。
姗姗来迟的JS函数
另一个 MySQL 9.0 带来的 “重磅” 特性是 ——Javascript 存储过程。
然而用 Javascript 写存储过程并不是什么新鲜事 —— 早在 2011 年，PostgreSQL 9.1 就已经可以通过plv8扩展编写 Javascript 存储过程了，MongoDB 也差不多在同一时期提供了对 Javascript 存储过程的支持。
如果查看 DB-Engine 近十二年的 “” ，不难发现只有 PostgreSQL 与 Mongo 两款 DBMS 在独领风骚 —— MongoDB (2009) 与 PostgreSQL 9.2 (2012) 都极为敏锐地把握住了互联网开发者的需求 —— 在 “JSON崛起” 的第一时间就添加（文档数据库），从而在过去十年间吃下了数据库领域最大的增长红利。
当然，MySQL 的干爹 —— Oracle 也在2014年底的12.1中添加了 JSON 特性与 Javascript 存储过程的支持 —— 而 MySQL 自己则不幸地等到了 2024 年才补上这一课 ——但已经太迟了！
Oracle 支持用 C，SQL，PL/SQL，Pyhton，Java，Javascript 编写存储过程。但在 PostgreSQL 支持的二十多种存储过程语言面前，只能说也是小巫见大巫，只能甘拜下风了：
不同于 PostgreSQL 与 Oracle 的开发理念，MySQL 的各种最佳实践里都不推荐使用存储过程 —— 所以 Javascript 函数对于 MySQL 来说是个鸡肋特性。然而即便如此，Oracle 还是把 Javascript 存储过程支持做成了一个MySQL企业版专属的特性 —— 考虑到绝大多数 MySQL 用户使用的都是开源社区版本，这个特性属实是发布了个寂寞。
日渐落后的功能特性
MySQL 在功能上缺失的绝不仅仅是是编程语言/存储过程支持，在各个功能维度上，MySQL 都落后它的竞争对手 PostgreSQL 太多了 —— 功能落后不仅仅是在数据库内核功能上，更发生在扩展生态维度。
来自 CMU 的 Abigale Kim 对主流数据库的可扩展性进行了研究：PostgreSQL 有着所有 DBMS 中最好的可扩展性（Extensibility），以及其他数据库生态难望其项背的扩展插件数量 ——375+，这还只是 PGXN 注册在案的实用插件，实际生态扩展总数已经破千。
这些扩展插件为 PostgreSQL 提供了各种各样的功能 —— 地理空间，时间序列，向量检索，机器学习，OLAP分析，全文检索，图数据库，让 PostgreSQL 真正成为一专多长的全栈数据库 —— 单一数据库选型便可替代各式各样的专用组件：MySQL，MongoDB，Kafka，Redis，ElasticSearch，Neo4j，甚至是专用分析数仓与数据湖。
当 MySQL 还落在“关系型 OLTP 数据库” 的窠臼时， PostgreSQL 早已经放飞自我，从一个关系型数据库发展成了一个多模态的数据库，最终成为了一个数据管理的抽象框架与开发平台。—— 它正在通过插件的方式，将整个数据库世界内化其中；已经不再是少数精英团队的前沿探索，而是成为了一种进入主流视野的最佳实践。
而在新功能支持上，MySQL 却显得十分消极 —— 一个应该有大量 Breaking Change 的“创新大版本更新”，不是糊弄人的摆烂特性，就是企业级的特供鸡肋，一个大版本就连鸡零狗碎的小修小补都凑不够数。
越新越差的性能表现
缺少功能也许并不是一个无法克服的问题 —— 对于一个数据库来说，只要它能将自己的本职工作做得足够出彩，那么架构师与DBA总是可以多费些神，用各种其他的数据积木一起拼凑出所需的功能。
MySQL 曾引以为傲的核心特点便是性能—— 至少对于互联网场景下的简单 OLTP CURD 来说，它的性能是非常不错的。然而不幸地是，这一点也正在遭受挑战：Percona 的博文中提出了一个令人震惊的结论：
MySQL 的版本越新，性能反而越差
根据 Percona 的测试，在 sysbench 与 TPC-C 测试下，最新 MySQL 8.4 版本的性能相比 MySQL 5.7 出现了平均高达20%的下降；而 MySQL 专家 Mark Callaghan 进一步进行了详细的性能回归测试，确认了这一现象：
MySQL 8.0.36 相比 5.6 ，QPS 吞吐量性能下降了 25% ～ 40% ！
尽管 MySQL 的优化器在 8.x 有一些改进，一些复杂查询场景下的性能有所改善，但分析与复杂查询本来就不是 MySQL 的长处与适用场景，只能说聊胜于无。相反，如果作为基本盘的 OLTP CRUD 性能出了这么大的折损，那确实是完全说不过去的。
ClickBench：MySQL 打这个榜图什么呢？
Peter Zaitsev 在博文中评论：“与 MySQL 5.6 相比，MySQL 8.x 单线程简单工作负载上的性能出现了大幅下滑。你可能会说增加功能难免会以牺牲性能为代价，但 MariaDB 的性能退化要轻微得多，而 PostgreSQL 甚至能在新增功能的同时显著提升性能”。
MySQL的性能随版本更新而逐步衰减，但在同样的性能回归测试中，PostgreSQL 性能却可以随版本更新有着稳步提升。特别是在最关键的写入吞吐性能上，最新的 PostgreSQL 17beta1 相比六年前的 PG 10 甚至有了 30% ～ 70% 的提升。
在 Mark Callaghan 的性能横向对比（sysbench 吞吐场景） 中，可以看到五年前 PG 11 与 MySQL 5.6 的性能比值（蓝），与当下 PG 16 与 MySQL 8.0.34 的性能比值（红）。PostgreSQL 和 MySQL 的性能差距在这五年间拉的越来越大。
几年前的业界共识是 PostgreSQL 与 MySQL 在简单 OLTP CRUD 场景下的性能基本相同。然而此消彼长之下，现在 PostgreSQL 的性能已经远远甩开 MySQL 了。PostgreSQL 的各种读吞吐量相比 MySQL 高 25% ～ 100% 不等，在一些写入场景下的吞吐量更是达到了 200% 甚至 500% 的恐怖水平。
MySQL 赖以安身立命的性能优势，已经不复存在了。
无可救药的隔离等级
如果只是性能不好，总归还有办法来优化修补。但如果是正确性出了问题，那真就是无可救药了。《》一文指出，在正确性这个体面数据库产品必须的基本属性上，MySQL 的表现一塌糊涂。
权威的分布式事务测试组织JEPSEN研究发现，MySQL 文档声称实现的可重复读/RR隔离等级，实际提供的正确性保证要弱得多 —— MySQL 8.0.34 默认使用的 RR 隔离等级实际上并不可重复读，甚至既不原子也不单调，连单调原子视图/MAV的基本水平都不满足。
MySQL 的 ACID 存在缺陷，且与文档承诺不符—— 而轻信这一虚假承诺可能会导致严重的正确性问题，例如数据错漏与对账不平。对于一些数据完整性很关键的场景 —— 例如金融，这一点是无法容忍的。
此外，能“避免”这些异常的 MySQL可串行化/SR隔离等级难以生产实用，也非官方文档与社区认可的最佳实践；尽管专家开发者可以通过在查询中显式加锁来规避此类问题，但这样的行为极其影响性能，而且容易出现死锁。
与此同时，PostgreSQL 在 9.1 引入的 可串行化快照隔离（SSI） 算法可以用极小的性能代价提供完整可串行化隔离等级 —— 而且 PostgreSQL 的 SR 在正确性实现上毫无瑕疵 —— 这一点即使是 Oracle 也难以企及。
李海翔教授在《》论文中，系统性地评估了主流 DBMS 隔离等级的正确性，图中蓝/绿色代表正确用规则/回滚避免异常；黄A代表异常，越多则正确性问题就越多；红“D”指使用了影响性能的死锁检测来处理异常，红D越多性能问题就越严重。不难看出，这里正确性最好（无黄A）的实现是 PostgreSQL SR，与基于PG的 CockroachDB SR，其次是略有缺陷 Oracle SR；主要都是通过机制与规则避免并发异常；而 MySQL 出现了大面积的黄A与红D，正确性水平与实现手法糙地不忍直视。
做正确的事很重要，而正确性是不应该拿来做利弊权衡的。在这一点上，开源关系型数据库两巨头 MySQL 和 PostgreSQL 在早期实现上就选择了两条截然相反的道路：MySQL 追求性能而牺牲正确性；而学院派的 PostgreSQL 追求正确性而牺牲了性能。在互联网风口上半场中，MySQL 因为性能优势占据先机乘风而起。但当性能不再是核心考量时，正确性就成为了 MySQL 的致命出血点。更为可悲的是，MySQL 连牺牲正确性换来的性能，都已经不再占优了，这着实让人唏嘘不已。
枯萎收缩的生态规模
对一项技术而言，用户的规模直接决定了生态的繁荣程度。瘦死的骆驼比马大，烂船也有三斤钉。MySQL 曾经搭乘互联网东风扶摇而起，攒下了丰厚的家底，它的 Slogan 就很能说明问题 —— “世界上最流行的开源关系型数据库”。
不幸的是在 2023 年，至少根据全世界最权威的开发者调研之一的结果来看，MySQL 的使用率已经被 PostgreSQL 反超了 ——最流行数据库的桂冠已经被 PostgreSQL 摘取。
特别是，如果将过去七年的调研数据放在一起，就可以得到这幅 PostgreSQL / MySQL 在专业开发者中使用率的变化趋势图（左上） —— 在横向科比的同一标准下，PostgreSQL 流行与 MySQL 过气的趋势显得一目了然。
对于中国来说，此消彼长的变化趋势也同样成立。但如果对中国开发者说 PostgreSQL 比 MySQL 更流行，那确实是违反直觉与事实的。
将 StackOverflow 专业开发者按照国家细分，不难看出在主要国家中（样本数 > 600 的 31 个国家），中国的 MySQL 使用率是最高的 —— 58.2% ，而 PG 的使用率则是最低的 —— 仅为 27.6%，MySQL 用户几乎是 PG 用户的一倍。
与之恰好反过来的另一个极端是真正遭受国际制裁的俄联邦：由开源社区运营，不受单一主体公司控制的 PostgreSQL 成为了俄罗斯的数据库大救星 —— 其 PG 使用率以 60.5% 高居榜首，是其 MySQL 使用率 27% 的两倍。
中国因为同样的自主可控信创逻辑，最近几年 PostgreSQL 的使用率也出现了显著跃升 —— PG 的使用率翻了三倍，而 PG 与 MySQL 用户比例已经从六七年前的 5:1 ，到三年前的3:1，再迅速发展到现在的 2:1，相信会在未来几年内会很快追平并反超世界平均水平。毕竟，有这么多的国产数据库，都是基于 PostgreSQL 打造而成 —— 如果你做政企信创软件生意，那么大概率已经在用 PostgreSQL 了。
抛开政治因素，用户选择使用一款数据库与否，核心考量还是质量、安全、效率、成本等各个方面是否“先进”。先进的因会反映为流行的果，流行的东西因为落后而过气，而先进的东西会因为先进变得流行，没有“先进”打底，再“流行”也难以长久。号称“最流行”的 MySQL，终究还是难敌时间的审判。
究竟是谁杀死了MySQL？
MySQL 曾经也辉煌过，但再精彩的演出也会落幕。
MySQL 正在死去 —— 更新疲软，功能落后，性能劣化，质量出血，生态萎缩，此乃天命，实非人力所能救也。但究竟是谁杀死了 MySQL，难道是 PostgreSQL 吗？Peter Zaitsev 在《》一文中控诉，Oracle 的不作为与瞎指挥最终害死了 MySQL；并在后续《》一文中指出了真正的根因：
MySQL 的知识产权被 Oracle 所拥有，它不是像 PostgreSQL 那种 “由社区拥有和管理” 的数据库，也没有 PostgreSQL 那样广泛的独立公司贡献者。不论是 MySQL 还是其分叉 MariaDB，它们都不是真正意义上像 Linux，PostgreSQL 这样由社区驱动的的原教旨纯血开源项目，而是由单一商业公司主导。
比起向一个商业竞争对手贡献代码，白嫖竞争对手的代码也许是更为明智的选择 —— AWS 和其他云厂商利用 MySQL 内核参与数据库领域的竞争，却不回馈任何贡献。于是作为竞争对手的 Oracle 也不愿意再去管理好 MySQL，而干脆自己也参与进来搞云 —— 仅仅只关注它自己的 MySQL heatwave 云版本，就像 AWS 仅仅专注于其 RDS 管控和 Aurora 服务一样。在 MySQL 之死上，云厂商也难辞其咎。
逝者不可追，来者犹可待。PostgreSQL 应该从 MySQL 上吸取教训 —— 尽管 PG 社区已经非常小心地避免出现一家独大的情况出现，但生态确实在朝着几家巨头云厂商作大垄断的不利方向发展。
—— 云厂商编写了开源软件的管控软件，组建了专家池，通过提供维护攫取了软件生命周期中的绝大部分价值，但却通过搭便车的行为将最大的成本 ——产研交由整个开源社区承担。
云上区——在数据库领域，我们已经在 MongoDB，ElasticSearch，Redis，以及 MySQL 上看到了这一现象，而 PostgreSQL 社区确实应当引以为鉴。
好在 PG 生态总是不缺足够头铁的人和公司，愿意站出来维护生态的平衡，反抗公有云厂商的霸权。例如，我自己开发的 PostgreSQL 发行版，旨在提供一个开箱即用、本地优先的开源云数据库 RDS 替代，将社区自建 PostgreSQL 数据库服务的底线，拔高到比云厂商 RDS PG 更高的水平线。
而另一个《》系列专栏则旨在扒开云服务背后的信息不对称，从而帮助公有云厂商更加体面，亦称得上是成效斐然。
尽管我是 PostgreSQL 的坚定支持者，但我也赞同 Peter Zaitsev 的观点：“如果 MySQL 彻底死掉了，开源关系型数据库实际上就被 PostgreSQL 一家垄断了，而垄断并不是一件好事，因为它会导致发展停滞与创新减缓。PostgreSQL 要想进入全盛状态，有一个 MySQL 作为竞争对手并不是坏事”。
—— 至少，MySQL 可以作为一个与鞭策激励，让 PostgreSQL 社区保持凝聚力与危机感，不断提高自身的技术水平，保持开放、透明、公正的社区治理模式，从而继续推动数据库技术的发展。
PostgreSQL 带着开源软件的初心与愿景继续坚定前进 —— 它将走上 MySQL 未走完的长路，写完 MySQL 未写完的诗篇，见到 MySQL 未见的世界，活成 MySQL 未曾活过的愿。在这，谨以一首《PG驶向云外，MySQL安魂九霄》，送给曾经的对手 —— MySQL。
PG驶向云外，MySQL安魂九霄
我那些残梦，灵异九霄
徒忙漫奋斗，满目沧愁
在滑翔之后，完美坠落
在四维宇宙，眩目遨游
我那些烂曲，流窜九州
云游魂飞奏，音愤符吼
在宿命身后，不停挥手
视死如归仇，毫无保留
黑色的不是夜晚，是漫长的孤单
看脚下一片黑暗，望头顶星光璀璨
叹世万物皆可盼，唯真爱最短暂
失去的永不复返，世守恒而今倍还
摇旗呐喊的热情，携光阴渐远去
人世间悲喜烂剧，昼夜轮播不停
纷飞的滥情男女，情仇爱恨别离
一代人终将老去，但总有人正年轻
References：OsChina，感谢原作者。
甲骨文向MySQL用户、开发者和客户的十项承诺
MySQL被并购将开源数据库将倒退十年
四分五裂的MySQL能否重整山河
前MySQL CEO呼吁更多创业公司加入开源运动
后Sun时代MySQL出路何在
PostgreSQL创始人:MySQL衰退属必然
MySQL陷内忧外患或已处于消亡的边缘
Oracle最终还是杀死了MySQL
MySQL已死，PostgreSQL当立
甲骨文向MySQL用户、开发者和客户的十项承诺
甲骨文/SUN交易案最新动向：甲骨文向MySQL用户、开发者、客户做出十项承诺。
2009年12月下旬消息，甲骨文公司与欧盟委员会就甲骨文SUN公司的交易案进行了建设性的讨论，并承诺将保持MySQL在数据库市场的竞争力。为了进一步获得欧盟的批准，甲骨文公司公开其十项承诺，内容如下：
1、保证存储引擎API持续可用性
甲骨文保证并阶段性加强MySQL的可插拔存储引擎架构，让用户可以灵活选择从本地和第三方产品提供存储引擎。此保证意味着MySQL当前的使用政策有效，允许符合SUN文件的存储引擎供应商接入MySQL数据库。
2、不主张承诺
作为版权持有人，甲骨文将改变SUN的现行政策，同时不得声称或威胁任何人，存储引擎第三方供应商必须基于GPL发布的，因为他们已经实行了应用编程接口有效，作为MySQL的可插入式存储引擎架构的一部分。商业许可无需通过Oracle请求。甲骨文将复制此承诺到与SUN有商业许可关系的存储供应商的合同当中。
3、许可证的承诺
当他们目前MySQL的OEM协议终止后，甲骨文将提供这些存储供应商与SUN相同的许可条件，不超过2014年。甲骨文将复制此承诺到与SUN有商业许可关系的存储供应商的合同当中。
4、承诺在今后加强MySQL基于GPL发布
MySQL后续版本，包括版本6，均将通过GPL发布。甲骨文公司不会在没有发布社区加强版的同时发布一个新的企业加强版。甲骨文公司将继续把MySQL社区版的所有版本的源代码公开，将免费提供。
5、支持并不是强制性的
MySQL客户不会被要求从甲骨文获得支持服务作为购买商业许可的条件。
6、 增加对MySQL的研发支出
甲骨文承诺提供可用于MySQL持续发展的适当资金(GPL的版本和商业版本)。 在未来3年，每年，甲骨文将在MySQL的研发上投入比SUN的最近财年(2400万美元)还要多，在交易完成之前。
7、成立MySQL客户顾问委员会
不迟于6个月后的一周年之际，甲骨文将创建并资助一个客户咨询委员会，包括最终用户和嵌入式客户提供指导和反馈，作为MySQL的发展优先事项，以及其他MySQL客户的重要问题。
8、成立MySQL存储引擎供应商咨询委员会
不迟于6个月后的一周年之际，甲骨文将创建并资助一个存储引擎供应商咨询委员会，提供指导和反馈，作为MySQL的发展优先事项，以及其他MySQL存储引擎供应商的重要问题。
9、 MySQL参考手册
对MySQL参考手册，甲骨文公司将继续保持更新和免费下载，质量保持与SUN所提供的一致。
10、 客户支持服务将继续
甲骨文将确保付费的最终用户和嵌入式客户提供MySQL的支持服务，根据客户的喜好更新订阅。
这些承诺在全球范围内，并持续到交易完成五周年。
MySQL被并购将开源数据库将倒退十年
有自由软件之父之称的Richard Stallman在2009年10月下旬发表一封公开信给欧洲委员会的委员Neelie Kroes，请求不要让甲骨文(Oracle)合并MySQL。知识生态国际(KEI, Knowledge Ecology International)及开放权利组织(ORG, Open Rights Group)等两个非营利组织也加入联名。这份公开信并张贴在KEI网站上。
公开信指出，甲骨文买下MySQL是为了防止其数据库软件授权与服务的市场遭到侵蚀，以保护其专有的数据库软件的高额收费。如果Oracle成功合并MySQL，可预见的是，MySQL这个软件平台的功能与性能的发展都将受限，对于其使用者造成很重的伤害。
九月间EC宣布要深入调查甲骨文与SUN的合并案，特别是合并MySQL对数据库市场的影响，也因此MySQL的相关争议也陆续浮出台面。日前MySQL 作者兼联合创办人Michael 'Monty' Widenius除了表态支持欧盟对甲骨文的深入调查之外，并建议甲骨文卖掉MySQL以解除市场疑虑。
甲骨文是“旧”市场领导者 MySQL是未来市场“新”星
Stallman整份文件则不断强调甲骨文和MySQL之间的竞争关系，以及甲骨文对于MySQL未来的缺乏承诺及保障，以期望说服EC阻止甲骨文合并MySQL。
他指出，甲骨文是私有数据库软件的龙头厂商，其软件是为大型企业而设计，而且在这块市场里有霸主的地位，然后收取非常昂贵的费用，赚进大把的钞票。但在其他市场里，甲骨文面临许多数据库软件商竞争对手，包括私有软件的Microsoft SQL Server、Sybase，及IBM DB2；另外还有FLOSS(Free/Libre/ and Open Source)平台，特别是MySQL。
从1998年开始，开源的网页服务器软件就有LAMP。LAMP也是Linux操作系统，Apache HTTP服务器软件，MySQL数据库，以及PHP网页描述语言的简称。这些软件被用来打造数以百万及的网络应用，根据升阳的数字，MySQL的下载量每天超过6.5万次。一般而言，使用者可以透过两种方式取得MySQL，大多数都是在GNU的通用公共授权(GPL)第二版的条款下自由而免费取得；另外也可以专属软件的付费授权方式取得。
随着时间的演进，MySQL在功能，稳定性，以及性能上不断改进，而且已经成为数据库市场中占有重要的地位，并受到开源社区的信赖──其重要性远非市场营收占有率可以衡量分析得出来的，Stallman表示。
MySQL对于私有软件的价格也带来重要的市场压力，让甲骨文及微软等业者的授权费趋于合理或更低，甚至也有许多企业在转向采用MySQL数据库。“如果甲骨文是今日旧据库市场的统治者，那么MySQL就是‘新’的新兴数据库市场的主导者，因此MySQL可以视为甲骨文未来的最重要竞争对手。”Stallman说。
开源数据库将会倒退数年
事实上甲骨文曾在2006年时就要买MySQL，但由于无法揭露它对MySQL未来的发展计划而遭拒，当时MySQL的管理者甚至担心，甲骨文此举只是想要防止MySQL的市场发展。
Stallman认为，相较之下SUN买下MySQL之所以让各界所接受，是因为它过去一向以倡导开放源码而广受好评，同时一般认为Sun能够给MySQL很好的市场定位。虽然被Sun买了之后有不小的人事变动，但大体来说，核心的软件产品仍有持续的扩大与改进。另一方面，MySQL作者 Widenius之前的公开信也指出：“SUN是MySQL最好的归宿。”
至于外界看法认为，甲骨文无法伤害MySQL，因为在GNU GPS v2.0管辖下，如果甲骨文未能开发程序代码，任何的其他企业或个人都可以接手MySQL未来的开发；另一看法认为，甲骨文是要以MySQL强化与微软 SQL Server的竞争。Richard Stallman都一一加以反驳。
他指出，MySQL使用平行授权的方式，可以透过收费授权所带进的营收来养FLOSS软件的开发。然而，一但MySQL被甲骨文所合并，甲骨文不只没有义务积极推销MySQL或以合理价格提供其商业授权；更没义务拿这些营收来改进MySQL。而且在相关决策上，甲骨文显然有利益冲突问题，恐怕会以保护其收费的数据库为优先。
Stallman表示，对于FLOSS数据库平台来说，MySQL被甲骨文合并将是一种倒退，可能瓦解MySQL的核心开发者社群。而要产生另一个足以与MySQL相提并论的数据库平台，恐怕还需要很多年的时间。
四分五裂的MySQL能否重整山河
在Oracle宣布收购Sun一个月之后的2009年9月下旬，MySQL的未来仍悬而未决，51CTO.com曾报道过业界对收购后MySQL前景的担忧。在领先的商业数据库供应商手中，MySQL这个领先的轻量级开源数据库还能够继续保持兴旺吗？到目前为止，形势好像并不乐观。
早在Oracle收购之前，MySQL社区就有了紧张的迹象。2008年在Sun收购MySQL后不久，许多重要的MySQL员工就开始陆续离开，其中包括 CEO Mårten Mickos和共同创始人Monty Widenius。Widenius更是公开抨击了由Sun领导的MySQL开发流程，批评发布周期太过匆忙以及缺乏质量控制。另一位共同创始人 David Axmark也在受够了Sun陈旧的企业文化和繁杂的办事方式后选择了离开。在51CTO.com之前关于MySQL两位创世人离职对Sun的影响一文中曾猜测Sun领导下的MySQL是否会更好？现在，该换Oracle领导的MySQL是否会更好了。
随着骨干成员大批出走，MySQL的发展碰到 了另一个难关：MySQL的分支开始出现，包括Drizzle和MariaDB，它们向用户和贡献者提供 Sun控制的主要分支之外的方式。Drizzle试图摆脱一些最近的MySQL版本中过多的功能，为云计算和Web应用服务器提供更合适的轻量级数据库。而MariaDB目标是与MySQL功能兼容，而且默认使用全新的transaction-capable存储引擎。可能更重要的是，MariaDB 的创建者不是别人，正是MySQL的开山鼻祖Widenius本人。
如果这些事还不能让MySQL的新东家Oracle头疼的 话，Widenius已经扔出了另一波攻势。上周，51CTO.com曾在5月13日报道过 Widenius宣布成立开放数据库联盟(Open Database Alliance)的消息，一个“供应商中立的组织”，他们的目标是要“成为MySQL开源数据库的业界枢纽，包括MySQL和衍生代码、二进制文件、培训、支持和MySQL社区和合作伙伴系统的改进。”值得注意的是，Oracle没有被列入开放数据库联盟的联系人名单。
对这一切感到为难的人绝不会少。今年3月，前MySQL员工，现在的Drizzle开发者Patrick Galbraith曾大声质疑现在哪个MySQL分支才能算得上“官方正式版”。这个问题的最终答案或许就是MySQL的命运。
Oracle能够重视MySQL吗？
当然，名义上MySQL只可能有一个真正的官方正式版：就是那个最初的MySQL，后来被Sun收购，并最终被Oracle获得的那个。Oracle目前拥有与MySQL的名字相关的所有版权，商标和其他知识产权——它在保护知识产权时一向不遗余力。MySQL甚至曾经向一些合作伙伴发出商标违反通知，只因为他们在其提供的服务中标注的是“MySQL support(MySQL支持)”，而不是“支持MYSQL数据库(support for MySQL databases)”。
虽然这方面做的不错，但是MySQL的品牌本身并不会让顾客感到舒心，他们担心一个开源数据库不会得到世界上最大的商业软件公司的应有重视。已经有一些客户质疑Oracle对MySQL的承诺，尤其是当它拥有利润丰厚的商业数据库时，对低端的开源产品的态度究竟会怎样。MySQL社区已经开始分裂并各自转向替代品，Oracle的MySQL的业务正逐渐变得缺乏吸引力。
但是，如果MySQL的支持率正在下降，Oracle更应该快点做出决断。Oracle必须努力恢复MySQL社区的信任和支持，否则就可能眼睁睁的看着它变成一把叉子——长出 Drizzle、MariaDB或者其它分支。为了做到这一点，Oracle必须要避免Sun在收购MySQL时犯的错误。从某种意义上说，想要 MySQL成功，Oracle要表现得不像Oracle一点。
开源项目的客户是出了名的挑剔。如果一个项目不能提供用户需要，用户可以立刻去找其他的——开发者也一样。有许多开源项目都出现了叉子的状况，也有观点认为这样的竞争是健康的。而对于Oracle来说，最好希望自己不要走错了路口。
如果MySQL变成叉子，谁会输，谁会赢？
巧合的是，在开源世界的另一个领地正在上演类似的情节。这个主角是glibc——Gnu standard C library(GNU标准C库)——Linux上运行的几乎所有软件都在用它。本月初，Debian项目决定用eglibc(Embedded glibc)，也就是glibc的一个分支来替换掉它。表面上看新的分支可以更好地为嵌入式系统编程服务，但社区里却可以听到些闲话说替换glibc的真正原因在于glibc主要维护者Ulrich Drepper的顽固不化。
eglibc的出现肯定不是偶然的。它与很久以前的一次争议事件遥相呼应，当时有一群从事Gnu C compiler(GCC，Gnu C编译器)的开发者由于受不了项目贡献模式的严格限制，分离出去形成了一个称为egcs的新分支。摆脱了官僚主义之后，egcs分支繁荣发展，而gcc的 主分支依旧停滞不前，最后以gcc的死去而其后egcs正式改名为gcc而告终，分支最终变成了主干。根据一些egcs开发者所说，他们从一开始就有这样 的打算。很难讲这次eglibc的维护者们是不是也有类似的想法。
Oracle和其他开源项目的维护者都应该在这里好好的上一课。缓慢的专制管理是许多开源软件的用户和贡献者所不愿意容忍的，而被企业等商业实体维护的项目特别容易受到这种影响。在Eric S. Raymond发表了他那篇论文大作“大教堂和集市”的12年之后，我们看到仍有太多的项目——尤其是企业——还是无法放掉自己的大教堂心态。
因此Oracle最好的行动方针应该是立即加入开放数据库联盟，并以积极的态度参与MySQL的开发，而且要全力保护由社区推动的开放的方式。Oracle将MySQL作为Sun的一项资产买下来，但是Sun一直没有抓住MySQL的重点，也不知道如何管理。如果Oracle想不出怎样比Sun 做的更好，那么它仍将拥有MySQL的名号，然而不幸的是，这个名号很快就会没有多大意义了。
前MySQL CEO呼吁更多创业公司加入开源运动
据国外媒体报道，MySQL前CEO马顿·米克斯（Marten Mickos）于2010年3月下旬在EclipseCon 2010会议上强调，开源已不再是失败者，但需要有更多创业公司通过开源软件赚钱。
软件业专家在EclipseCon公司举办的会议上讨论了开源的未来。米克斯强调，通过开源赚大把钞票的创业公司太少。倒是拥有成熟商业模式的 IBM、微软、甲骨文和Apache Software、Eclipse、Linux和Mozilla基金会等公司为开源发展不懈努力。米克斯说：“我们希望有非常棒的创业公司通过开源赚上数百万、甚至数十亿美元，但目前还没有实现这一目标。开源领域有大量成功的赚钱公司如红帽、 JBoss、MySQL及XenSource，但光有这些还远远不够。”
米克斯最近出任开源云技术创业公司Eucalyptus的CEO。MySQL于2008年被Sun收购，甲骨文今年1月完成对Sun的收购后，获得 MySQL。米克斯说：“MySQL能够为开源运动贡献大量GPL代码，因为该领域一直有营收。”米克斯称，有部分人士批评MySQL的双重许可计划，即 公司一方面通过开源提供软件，同时向要求提供支持服务的用户收费。
Apache Software基金会总裁贾斯汀·伊伦科朗茨（Justin Erenkrantz）也强调有必要保证开源营收。伊伦科朗茨说：“需要维持商业公司赚钱的生态系统，便于开发人员为开源做贡献的同时能获得一份收入，这 就需要开源社区和创业公司共同保证开源的未来。”
开源分析与咨询公司RedMonk分析师斯蒂芬·奥格雷迪（Stephen O'Grady）对开源未来表达了不同的观点，强调分散化的开发和基础设施。奥格雷迪还强调通过对信息进行聚合、分析，挖掘数据潜力。尽管有部分观点认定开源无法创新，只是使市场商品化，但奥格雷迪指出，开源已在云技术领域引发了创新。他同时承认，开源也是市场商品化的积极推进者。
后Sun时代MySQL出路何在
Oracle对于Sun的合并过程已经完成。2010年4月中旬，欧盟委员会也已经对该合并表示了祝福。Oracle的标识已经骄傲地显示给任何在浏览器中输入 “sun.com”的人。因此如果你访问mysql.com网站，几乎看不到任何人提到Sun(Sun在2008年用10亿美元收购了MySQL)，而在这个网页的最底下一行印着大红的Oracle标识。
看起来好像那些无休止的诉讼案情摘要、听证会、唇枪舌剑等等所有事情都不曾发生过一样。现在，全球各地的数据库管理员、IT经理和小型网站运营商继续像往常一样工作，MySQL继续在服务器上运行并回应着数据库查询。但是现在，是Oracle拥有了MySQL的版权。所以，这个问题依然存在：MySQl这个流行的开源软件数据库的未来会怎样？众多依赖于它的机构的未来会怎样？
这是一个棘手的问题。这个问题的答案主要取决于MySQL在你的企业中发挥的作用、你使用的许可证类型、你想花的钱的总数、你要采购什么以及你在未来要与谁合作等等。使这个事情更加复杂的是，MySQL是世界上最著名的开源软件项目和业务之一，因此，任何有关MySQL的讨论都会变成一场有关开源软件许可证的争论，例如GPL许可证。
MySQL的今天和明天
对于MySQL爱好者的好消息是：它不会很快就无人管理而枯萎和死亡。Oracle已经公开保证它将比Sun投入更多的资金开发这个数据库，至少在未来三年之内是如此。MySQL的社区版将继续得到改善。该版本是根据GPL许可证发布的，所有的源代码都是免费的。
这些保证表明，普通的MySQL用户不需要考虑在未来几年里是否放弃MySQL的问题。如果你对于所使用的数据库的版本满意，只要你有一个编译器，就能够一直保持它运行。
有一些充分的历史证据表明，Oracle将让用户更轻松地继续使用MySQL，而不再需要编译器。一位很熟悉Oracle在收购开源软件数据库公司 Sleepycat之后如何使其成熟的开发人员说，这次收购对于所有人都是非常不错的。现在Sleepycat的工程师人数比以前多多了，而且并未改变过该数据库的许可证。
一位不愿透露姓名的Oracle开发人员说，“4年之后，我们大家都还在这里。人人仍在工作并且很快乐。Oracle是很不错的工程师之家。”
当然，这种保证还不足以安抚每一个人紧张的神经。MySQL网站显著地有别于Sleepycat.com(后者并重定向至Oracle网站)的事实也许不仅仅是一个疏忽。Oracle管理层很清楚人们对于MySQL的未来之路充满了混乱之感，所以把mysql.com网站重定向到oracle.com网站，只会让那些在Sun被收购之后仍然感到担心的人们更加不安。
你的许可证还是我的许可证？
机构和开发人员并非只是简单地担心MySQL作为一种产品的未来，而是担心Oracle拥有该数据库及其许可证的方式是否会影响到许可证的授权。
MySQL的创始人之一Monty Widenius也是公开反对Sun与Oracle合并的人士之一。他在2009年离开了Sun去了MariaDB，这是在Monty Program AB公司之下开发的一种新版本的MySQL源代码。
Widenius一直在游说欧盟委员会阻止Oracle与Sun的合并。他争辩说，允许Oracle控制MySQL版权对于欧洲和整个社会来说都不是好事。他的理由是，像MySQL那样，产品建立在开源软件数据库基础上的公司，只能够向不愿受GPL许可证束缚的用户提供商用许可证才能持续生存下去。
因此，他争辩说，如果Oracle成为单独的版权拥有者，就不会允许任何竞争者销售商用许可证。(原先MySQL公司也一直坚持保留全面的版权，要求所有的作者签署协议把版权授予该公司。这项权利就意味着他们且只有他们能够出售商用许可证，而不必理会GPL协议。)
迫使用户采用GPL许可证的麻烦其实并不在于这个有争议的许可证本身，而在于这件事情的细节会变得更加复杂。比如说，有些人认为，该许可证可适用于和所有软件密切相关的驱动程序和连接协议。而其他人则认为，这种想法过于大言不惭了。
在过去，MySQL的销售人员会很有效地利用潜在客户对于GPL许可证的混乱想法，设法说服他们相信，选择一个商用许可证会更简单，可以消除未来可能出 现的任何代价昂贵的法律纠纷。当然，出售商用许可证可以喂饱饥饿的开发人员的肚子。这种销售方法已经证明是一个有效的和有利可图的吓唬人的策略。
PostgreSQL创始人:MySQL衰退属必然
MySQL被称为是最受欢迎的开源数据库，如今它的前途因为Oracle与Sun并购交易存在不确定性而变得扑朔迷离，可能会导致大量用户流失。PostgreSQL创始人之一的Bruce Momjian在2009年12月中旬接受IT168记者采访时表示“MySQL衰退，这并不是一件很令人惊奇的事情。”Bruce Momjian认为MySQL衰退缘自2个方面的原因，其一，MySQL定位不明晰，其二MySQL不是一个纯粹的开源数据库。
Bruce Momjian进一步解释：“之所以说MySQL定位不明晰，是因为其初始目标定位在网络应用的用户层面上，而互联网企业要求的是一个快速反应时间和较小的用户量，但相对大用户来说，MySQL就有点捉襟见肘了。虽然MySQL非常努力去试图满足大客户的应用，想扩展企业级应用标准，但因为前期开发的框架不是很明晰，导致不是很成功，结果是我们看到的先是被Sun收购，又被Oracle并购。”
作为一个小型关系型数据库管理系统，MySQL的开发者为瑞典MySQL AB公司，并在2008年1月16日被Sun微系统公司以10亿美元的价格收购。
Bruce Momjian认为：“MySQL数据库是一个公司的一产品，是一个公司做了绝大部分开发的工作，所以MySQL不是完全意义上的开源数据库，这是个劣势，不能得到绝大多数人的支持，或让社区更多人参与进来。”
IDC的数据显示，2008年MySQL营收为4000万美元,市场份额为0.2%。MySQL每天下载量约为6万次,是当前应用最广泛的开源数据库，按照欧盟委员会的说法，其实际竞争力远高于按市场份额计算应有的水平。同时欧盟委员会还表示担忧：甲骨文收购开源软件数据库软件MySQL可能会消除重要的竞争对手和提高这种软件的价格。尽管Oracle承诺会保持MySQL的独立性，众多反对者还是担心，如果MySQL被最大的私有数据库厂商 Oracle收归麾下，可能遭到Oracle的抛弃甚至打压。
选择pgsql还是mysql
mysql出现在1994年，现在所有权归属oracle，创始人现在又发布了新的免费开源数据库MariaDB，现在开源关系型数据库领域，mysql使用确实是最广泛的，官方说许多世界上最大、发展最快的组织都在使用mysql。
pgsql又称PostgresSQL，出现在1986年，官方标榜自己是世界上最先进最高级的开源关系型数据库。
pgsql和mysql简介：
pgsql的一方面可以跟oracle相媲美，可靠性是pgsql的最高优先级，数据一致性与完整性也是pgsql的高优先级特性；
mysql和pgsql都出现在一些高流量的web站点上，都能用在大型分布式系统上，都支持事务，都支持全文索引；
mysql现在已经支持嵌入式应用，而pgsql依然坚守在传统B/S架构上；
mysql能够进行快速地读取和大量的查询操作，不过在复杂特性与数据完整性检查方面不太尽如人意；
pgsql是针对事务性企业级应用严肃、功能完善的数据库，支持强ACID特性，会做很多数据完整性检查；
mysql上myISAM存储引擎因为执行很少的数据完整性检查，所以速度快，对于敏感数据，对读写要求高的数据，支持ACID特性的InnoDB则是个更好的选择，相反pgsql是个只有单一存储引擎完全集成的数据库；
mysql与pgsql都是高可配置的，通过参数调整性能，也可以调整查询与事务特性，他们都支持通过扩展添加额外的功能；
pgsql可靠性更好，稳定性很强，在保护数据安全方面更擅长，并且是社区项目，不会陷入商业厂商牢笼之中；
mysql的普及更广一些，学习资料更多，熟练使用的人更多，所以选择mysql的企业很多。
pgsql相比mysql的优势：
pgsql存储过程的功能支持要比mysql好，具备本地缓存执行计划的能力；
pgsql对表连接支持更完整，优化器的功能更完整，支持的索引类型很多，复杂查询能力较强；
pgsql主备复制属于物理复制，支持异步、同步、半同步复制，mysql基于binlog的逻辑复制，是异步复制，pgsql数据的一致性更加可靠，复制性能更高，对主机性能的影响也更小；
pgsql支持json数据类型，而mysql不支持，mysql字符型有长度限制，而pgsql的text类型无限长，可以使用xml xpath，用pgsql的话，mongodb这样文档数据库就省了；
pgsql是完全免费开源的，而mysql归属oracle后，开源程度大不如以前；
pgsql在GIS领域多年来处于优势地位，有丰富的几何类型，支持极其丰富的空间函数，可以建立R树、GIST树等空间索引，instagram就是因为pgsql的空间数据库扩展postgis远远强于mysql的my spatial而采用的pgsql；
pgsql有极其强悍的sql编程能力，有非常丰富的统计函数和统计语法支持，可用多种语言写存储过程，对R支持也非常好，这一点mysql就差的很远，腾讯内部数据存储主要用mysql，但是数据分析主要是hadoop+pgsql；
pgsql有多种集群架构可选择，plproxy可以支持语句级的镜像或分片，slony可以进行字段级的同步设置，standby可以构建WAL文件级或流式的读写分离集群，同步频率和集群策略调整方便，操作非常简单；
pgsql支持topology、pgrouting等功能强大、方便使用的GIS扩展，例如可以用pgrouting计算路径规划；
pgsql数据库方便QGIS等GIS工具连接和图层展示等操作；
mysql相比pgsql的优势：
mysql采用索引组织表，这种存储方式非常适合基于主键匹配的查询、删改操作，但是对表结构设计存在约束；
mysql的优化器较简单，系统表、运算符、数据类型的实现都很精简，非常适合简单的查询操作；
mysql分区表的实现要优于pgsql的基于继承表的分区实现，主要体现在分区个数达到上千上万后的处理性能差异较大；
mysql的存储引擎插件化机制，使得它的应用场景更加广泛，比如除了Innodb适合事务处理场景外，Myisam适合静态数据的查询场景；
mysql也支持空间索引，是用R树实现的空间索引，但空间函数等功能不如pgsql丰富，空间查询比pgsql慢；
pgsql更适合严格的企业应用场景，比如金融、电信、ERP、CRM等，mysql更适用业务逻辑相对简单、数据可靠性要求更低的互联网场景，比如google、facebook、淘宝等。
下图是redis、mongo、pgsql、mysql在一个空间查询场景下的性能对比：
pgsql支持的几种高级插件：
postgis提供丰富的空间数据类型和空间函数。
pgrouting 用来进行路径规划。
postgis_topology 用于管理点、线、面等拓扑对象。
postgis_sfcgal 用于实现3D相关算法。
fuzzystrmatch 字符串相似度计算。
address_standardizer 用于地址标准化。
pg_trgm 用于分词索引。
结论：
如果空间操作比较多，比较复杂，那就得选择pgsql；
如果对数据安全性和稳定性要求很高，pgsql是更好的选择；
如果业务场景没那么复杂，mysql完全可以胜任。
MySQL陷内忧外患或已处于消亡的边缘
甲骨文为了在收购Sun交易中获得MySQL费尽心思，才最终获得监管机构的批准，目前来看这些努力可能是在浪费时间和金钱，人们或将突然发现：内忧外患的MySQL已经处于消亡的边缘。
在2010年4月举行的MySQL大会上，MySQL之父迈克尔.韦德纽斯(Michael Widenius)和大名鼎鼎的MySQL架构师布莱恩.阿克尔(Brian Aker)分别发表演讲，他们坚信任何一家公司都不可能成为MySQL开发或支持服务的唯一提供商。这些MySQL名人的做法对甲骨文来说是一种考验，将验证甲骨文与MySQL社区配合和容忍不同意见的程度。
2010年5月，旧金山新创公司Clustrix公开宣称，自己的产品更强大更优秀，可以完成MySQL做不好的事情，可扩展至存储数十亿条数据，完全可以取代MySQL。Clustrix产品中不存在MySQL的 DNA，但它可以与MySQL协议互通，这样应用程序再也无需进行代码移植，它的存在无疑会伤害MySQL的付费业务。
该产品被称为针对互联网规模级应用程序的首款集群数据库系统，据说它遵循了应用程序服务器和存储系统突变成可扩展式、群集产品的进化路线。它具有NoSQL的key/value存储的巨大可扩容能力和高性能，而且封装在3节点服务器CLX 4010设备内的SQL具有可靠的ACID测试相关功能，该硬件设备足以处理高负荷的读/写数据操作。
这三个或更多机架式设备都需要运行一个被称为Sierra集群数据库引擎的软件。据Clustrix称，用户希望或需要多大的可扩展性，取决于把多少节点设备加入到机架中。Sierra群集数据库引擎是一个非共享式执行环境，包含Sierra并行规划器(Parallel Planner)和Sierra分布式执行引擎(Distributed Execution Engine)。它把查询任务提供给分布式数据，而不是像RDBMS那样把数据提供给查询任务。
这意味着Clustrix群集数据库应该能够以最大的并行性执行查询语句，许多同步查询具有最大的并发性。这将带来极高的可扩展性、读/写操作性能、可用 性、在线调整纲要、自我修复和自我管理。
Clustrix团队从Isilon Systems那儿学到不少经验，后者层针对存储系统开发过类似的高并行和分布式产品。Clustrix已经从风险投资机构那儿获得了1800万美元来研 发可扩展数据库。
Clustrix群集数据库的目标用户群是面向事务处理的云计算服务提供商、企业和社交网站类互联网公司，它们在处理互联网生活中令人难以置信的繁琐数据 时，为了获取所需的扩展性，不得不忍受在应用程序层不断进行合库和拆库的操作。同样在解决该问题的还有开源项目 Hadoop和Cassandra，以及谷歌的BigTable。
要想扩容MySQL数据库，通常需要许多令人痛苦的定制化编程，这是一个成本高且耗时的工作，而且在单实例数据库中很难找到互联网规模的关系数据库功能。
Clustrix承诺，借助于它的产品，人们不再需要这类代码编写工作。Clustrix的群集数据库系统能够以增量和无缝方式扩容至数百个节点，运行时就像一个单一实例数据库一样，具有全部关系数据库功能和一致的即时事务处 理。
该工具可以被透明和不中断的部署到分片、非分片和复制MySQL环境中。当客户需要增加更多的CLX 4010节点时，这个分布式和并行体系架构可以自动发布数据到新的节点，即使在写数据负荷非常重的情况下，也能实现线性提高性能。它通过自动负载均衡、失效切换、还原和自我修复实现高可用性。
Clustrix双核及四核设备包含两个1Gbps以太网口和两个20Gbps的 InfiniBand背板端口，同时还装配32GB RAM和7个160GB固态硬盘。三节点设备的报价是109995美元。其表示之前它已经开始销售这些产品，并且在今年第一季度达成第一笔交易。据称该公司目前已经收到不少订单，很明显对某些MySQL客户来说，他们的产品比较有吸引力。
Oracle最终还是杀死了MySQL？
2024年6月消息，2008年，Oracle收购了Sun公司，从而也拥有了MySQL，互联网上关于Oracle何时会“扼杀MySQL”的讨论此起彼伏。
当时流传着各种理论：从彻底扼杀 MySQL 以减少对 Oracle 专有数据库的竞争，到干掉 MySQL 开源项目，只留下 “MySQL企业版” 作为唯一选择。这些谣言的传播对 MariaDB，PostgreSQL 以及其他小众竞争者来说都是好生意，因此这些谣言在当时传播得非常广泛。然而实际上，Oracle 最终把 MySQL 管理得还不错。MySQL 团队基本都保留下来了，由 MySQL 老司机 Tomas Ulin 掌舵。MySQL 也变得更稳定、更安全。许多技术债务也解决了，许多现代开发者想要的功能也有了，例如 JSON支持和高级 SQL 标准功能的支持。
虽然有 “MySQL企业版”，它实际上关注的是开发者不太在乎的企业需求：如可插拔认证、审计、防火墙等。虽然也有专有的 GUI 图形界面、监控与备份工具（例如 MySQL 企业监控），但同样有许多开源和商业软件竞争者，因此并没有产生特别大的供应商锁定效应。在这段时间里，有人也常为 Oracle 辩护，因为许多人都觉得 MySQL 会遭受虐待，就因为 —— 它是Oracle。在那段期间，Oracle 一致遵守了这个众所周知的开源成功的黄金定律：“转换永远不应该妨碍采用。”
注：“Conversion should never compromise Adoption” 这句话指在开发或改进开源软件时，转换或升级过程中的任何变动都不应妨碍现有用户的使用习惯或新用户的加入。
然而近些年来，随着 Oracle 推出了 “MySQL Heatwave”（一种 MySQL 云数据库服务），事情开始起变化了； 其引入了许多 MySQL 社区版或企业版中没有的功能，例如加速分析查询与机器学习。在“分析查询”上，MySQL 的问题相当严重，到现在甚至都不支持并行查询。市场上新出来的 CPU 核数越来越多，都到几百个了，但单核性能并没有显著增长，而这严重制约了 MySQL 的分析性能提升 —— 不仅仅是分析应用的查询受限，像日常应用里简单的 GROUP BY 查询也会受影响。（备注：MySQL 8 对 DDL 有一些 并行支持，但查询没有这种支持）
这么搞的原因，是不是希望用户能够有更多理由去买 MySQL Heatwave？但或者，人们其实也可以直接选择用分析能力更强的 PostgreSQL 和 ClickHouse。
另一个开源 MySQL 较弱的领域是向量检索。其他主流开源数据库都已经添加了向量检索功能，MariaDB 也正在努力实现这个功能，但就目前而言，MySQL 生态里只有云上限定的 MySQL Heatwave 才有这个功能，这实在在是令人遗憾。
然后是最奇怪的决策 —— Javascript 支持是一个只在企业版中提供的功能，主流观点认为 MySQL 应该竭尽所能地去赢得 Javascript 开发者的心，而现在很多 JS 开发者都更倾向于更简单的 MongoDB 了。
上述举措都违背了前面提到的开源黄金法则 —— 因为它们显然限制了 MySQL 的采用 —— 不论是这些“XX限定”的特定功能，还是对 MySQL 未来政策变化的担忧。
如果这还不够，MySQL 的性能也出现了严重下降，似乎是因为多年来对性能工程部门的忽视。与MySQL 5.6 相比，单线程简单工作负载上的性能出现了大幅下滑。你可能会说增加功能难免影响性能，但 MariaDB 的性能退化要轻微得多，而 PostgreSQL 甚至能在 新增功能的同时显著提升性能。
显然无法窥视甲骨文管理团队的讨论，也不能说这到底是蠢还是坏，但过去几年的这些产品决策，显然不利于MySQL的普及，特别是在同一时间，PostgreSQL 在引领用户心智上大步向前，在 DB-Engines 排名上大幅缩小了与 MySQL 的热度差距，而根据 2023 StackOverflow 开发者调查，甚至已经超过 MySQL 成为最流行的数据库了。
无论如何，除非甲骨文转变其关注点，顾及现代开发者对关系数据库的需求，否则 MySQL 将坐以待毙 —— 无论是被 Oracle 的行为杀死，还是被 Oracle 的不作为杀死。
原文：Percona Blog，作者 Peter Zaitsev。Percona 是 MySQL 生态的重要贡献者，开发了知名的PT系列工具，MySQL备份工具，监控工具与发行版。
译者：冯若航，网名 Vonng，Pigsty 作者，PostgreSQL 专家与布道师。数据库老司机，云计算泥石流。
MySQL已死，PostgreSQL当立
2024年7月MySQL v9.0 终于发布了，距离上一次大版本更新 8.0 (2016-09) 已经过去整整八年。然而这个空洞无物的所谓 “创新版本” 却犹如一个恶劣的玩笑，宣告着 MySQL 正在死去。
空洞无物的创新版本
糊弄了事的向量类型
姗姗来迟的JS函数
日渐落后的功能特性
越新越差的性能表现
无可救药的隔离等级
枯萎收缩的生态规模
是谁杀死了MySQL?
PG驶向云外，MySQL安魂九霄
PostgreSQL 正在高歌猛进，而 MySQL 却日薄西山，作为 MySQL 生态主要抗旗者的 Percona 也不得不悲痛地承认这一现实，连发了三篇《》，《》，《》，公开表达了对 MySQL 的失望与沮丧；Percona 的 CEO Peter Zaitsev 也直言不讳道：有了 PostgreSQL，谁还需要 MySQL 呢？—— 但如果 MySQL 死了，PostgreSQL 就真的垄断数据库世界了，所以 MySQL 至少还可以作为 PostgreSQL 的磨刀石，让 PG 进入全盛状态。
有的数据库正在吞噬数据库世界，而有的数据库正在黯然地凋零死去。
MySQL is dead，Long live PostgreSQL！
空洞无物的创新版本
MySQL 官网发布的"What's New in MySQL 9.0"介绍了 9.0 版本引入的几个新特性，而一文对此做了扼要的总结：
然后呢？就这些吗？这就没了！？
这确实是让人惊诧不已，因为 PostgreSQL 每年的大版本发布都有无数的新功能特性，例如计划今秋发布的还只是 beta1，就已然有着蔚为壮观的新增特性列表：
而最近几年的 PostgreSQL 新增特性甚至足够专门编成一本书了。比如《》便收录了 PostgreSQL 最近七年的重要新特性 —— 将目录塞的满满当当：
回头再来看看 MySQL 9 更新的六个特性，后四个都属于无关痛痒，一笔带过的小修补，拿出来讲都嫌丢人。而前两个向量数据类型和JS存储过程才算是重磅亮点。
BUT ——
MySQL 9.0 的向量数据类型只是BLOB类型换皮 —— 只加了个数组长度函数，而这种程度的功能，28年前PostgreSQL 诞生的时候就支持了。而 Javascript 存储过程支持竟然还是一个企业版独占特性，开源版不提供 —— 同样的功能，13年前的 PostgreSQL 9.1 就已经有了。
时隔八年的 “创新大版本” 更新就带来了俩“老特性”，其中一个还是企业版特供。“创新”这俩字，在这里显得如此辣眼与讽刺。
糊弄了事的向量类型
2023年，AI爆火，带动了向量数据库赛道。当下几乎所有主流 DBMS 都已经提供向量数据类型支持 ——MySQL 除外。用户可能原本期待着在 9.0 创新版，向量支持能弥补一些缺憾，结果发布后等到的只有震撼 ——竟然还可以这么糊弄？
在 MySQL 9.0 的官方文档上，只有三个关于向量类型的函数。抛开与字符串互转的两个，真正的功能函数就一个VECTOR_DIM：返回向量的维度！（计算数组长度）
向量数据库的门槛不是一般的低 —— 有个向量距离度量函数就行（内积，10行C代码，小学生水平编程任务），这样可以通过全表扫描求距离 +ORDER BY d LIMIT n实现向量检索，至少是个可用的状态。
但 MySQL 9 甚至连这样一个最基本的向量距离函数都懒得去实现，这绝对不是能力问题，而是 Oracle 根本就不想好好做 MySQL 了。老司机一眼就能看出这里的所谓 “向量类型” 不过是BLOB的别名 —— 它只管你写入二进制数据，压根不管用户怎么查找使用。最后交付个十分钟就能写完的东西糊弄了事。
不糊弄的例子可以参考 MySQL 的老对手 PostgreSQL。在过去一年中，PG 生态里就涌现出了至少六款向量数据库扩展（pgvector，pgvector.rs，pg_embedding，latern，pase，pgvectorscale），并在你追我赶的赛马中卷出了新高度。最后的胜出者是 2021 年就出来的pgvector，它在无数开发者、厂商、用户的共同努力下，站在 PostgreSQL 的肩膀上，很快便达到了许多专业向量数据库都无法企及的高度，甚至可以说凭借一己之力，干死了这个数据库细分领域。
在这一年内，pgvector性能翻了 150 倍，功能上更是有了翻天覆地的变化 ——pgvector提供了 float向量，半精度向量，bit向量，稀疏向量几种数据类型；提供了L1距离，L2距离，内积距离，汉明距离，Jaccard距离度量函数；提供了各种向量、标量计算函数与运算符；支持 IVFFLAT，HNSW 两种专用向量索引算法（扩展的扩展 pgvectorscale 还提供了 DiskANN 索引）；支持了并行索引构建，向量量化处理，稀疏向量处理，子向量索引，混合检索，可以使用 SIMD 指令加速。这些丰富的功能，加上开源免费的协议，以及整个 PG 生态的合力与协同效应 —— 让pgvector大获成功，并与 PostgreSQL 一起，成为无数 AI 项目使用的默认（向量）数据库。
拿pgvector与来比似乎不太合适，因为 MySQL 9 所谓的“向量”，甚至都远远不如 1996 年 PG 诞生时自带的“多维数组类型” —— “至少它还有一大把数组函数，而不是只能求个数组长度”。然而向量数据库的宴席都已经散场了，MySQL 都还没来得及上桌 —— 它完美错过了下一个十年 AI 时代的增长动能，正如它在上一个十年里错过互联网时代的JSON文档数据库一样。
姗姗来迟的JS函数
另一个 MySQL 9.0 带来的 “重磅” 特性是 ——Javascript 存储过程。
然而用 Javascript 写存储过程并不是什么新鲜事 —— 早在 2011 年，PostgreSQL 9.1 就已经可以通过plv8扩展编写 Javascript 存储过程了，MongoDB 也差不多在同一时期提供了对 Javascript 存储过程的支持。
如果查看 DB-Engine 近十二年的 “” ，不难发现只有 PostgreSQL 与 Mongo 两款 DBMS 在独领风骚 —— MongoDB (2009) 与 PostgreSQL 9.2 (2012) 都极为敏锐地把握住了互联网开发者的需求 —— 在 “JSON崛起” 的第一时间就添加（文档数据库），从而在过去十年间吃下了数据库领域最大的增长红利。
当然，MySQL 的干爹 —— Oracle 也在2014年底的12.1中添加了 JSON 特性与 Javascript 存储过程的支持 —— 而 MySQL 自己则不幸地等到了 2024 年才补上这一课 ——但已经太迟了！
Oracle 支持用 C，SQL，PL/SQL，Pyhton，Java，Javascript 编写存储过程。但在 PostgreSQL 支持的二十多种存储过程语言面前，只能说也是小巫见大巫，只能甘拜下风了：
不同于 PostgreSQL 与 Oracle 的开发理念，MySQL 的各种最佳实践里都不推荐使用存储过程 —— 所以 Javascript 函数对于 MySQL 来说是个鸡肋特性。然而即便如此，Oracle 还是把 Javascript 存储过程支持做成了一个MySQL企业版专属的特性 —— 考虑到绝大多数 MySQL 用户使用的都是开源社区版本，这个特性属实是发布了个寂寞。
日渐落后的功能特性
MySQL 在功能上缺失的绝不仅仅是是编程语言/存储过程支持，在各个功能维度上，MySQL 都落后它的竞争对手 PostgreSQL 太多了 —— 功能落后不仅仅是在数据库内核功能上，更发生在扩展生态维度。
来自 CMU 的 Abigale Kim 对主流数据库的可扩展性进行了研究：PostgreSQL 有着所有 DBMS 中最好的可扩展性（Extensibility），以及其他数据库生态难望其项背的扩展插件数量 ——375+，这还只是 PGXN 注册在案的实用插件，实际生态扩展总数已经破千。
这些扩展插件为 PostgreSQL 提供了各种各样的功能 —— 地理空间，时间序列，向量检索，机器学习，OLAP分析，全文检索，图数据库，让 PostgreSQL 真正成为一专多长的全栈数据库 —— 单一数据库选型便可替代各式各样的专用组件：MySQL，MongoDB，Kafka，Redis，ElasticSearch，Neo4j，甚至是专用分析数仓与数据湖。
当 MySQL 还落在“关系型 OLTP 数据库” 的窠臼时， PostgreSQL 早已经放飞自我，从一个关系型数据库发展成了一个多模态的数据库，最终成为了一个数据管理的抽象框架与开发平台。—— 它正在通过插件的方式，将整个数据库世界内化其中；已经不再是少数精英团队的前沿探索，而是成为了一种进入主流视野的最佳实践。
而在新功能支持上，MySQL 却显得十分消极 —— 一个应该有大量 Breaking Change 的“创新大版本更新”，不是糊弄人的摆烂特性，就是企业级的特供鸡肋，一个大版本就连鸡零狗碎的小修小补都凑不够数。
越新越差的性能表现
缺少功能也许并不是一个无法克服的问题 —— 对于一个数据库来说，只要它能将自己的本职工作做得足够出彩，那么架构师与DBA总是可以多费些神，用各种其他的数据积木一起拼凑出所需的功能。
MySQL 曾引以为傲的核心特点便是性能—— 至少对于互联网场景下的简单 OLTP CURD 来说，它的性能是非常不错的。然而不幸地是，这一点也正在遭受挑战：Percona 的博文中提出了一个令人震惊的结论：
MySQL 的版本越新，性能反而越差
根据 Percona 的测试，在 sysbench 与 TPC-C 测试下，最新 MySQL 8.4 版本的性能相比 MySQL 5.7 出现了平均高达20%的下降；而 MySQL 专家 Mark Callaghan 进一步进行了详细的性能回归测试，确认了这一现象：
MySQL 8.0.36 相比 5.6 ，QPS 吞吐量性能下降了 25% ～ 40% ！
尽管 MySQL 的优化器在 8.x 有一些改进，一些复杂查询场景下的性能有所改善，但分析与复杂查询本来就不是 MySQL 的长处与适用场景，只能说聊胜于无。相反，如果作为基本盘的 OLTP CRUD 性能出了这么大的折损，那确实是完全说不过去的。
ClickBench：MySQL 打这个榜图什么呢？
Peter Zaitsev 在博文中评论：“与 MySQL 5.6 相比，MySQL 8.x 单线程简单工作负载上的性能出现了大幅下滑。你可能会说增加功能难免会以牺牲性能为代价，但 MariaDB 的性能退化要轻微得多，而 PostgreSQL 甚至能在新增功能的同时显著提升性能”。
MySQL的性能随版本更新而逐步衰减，但在同样的性能回归测试中，PostgreSQL 性能却可以随版本更新有着稳步提升。特别是在最关键的写入吞吐性能上，最新的 PostgreSQL 17beta1 相比六年前的 PG 10 甚至有了 30% ～ 70% 的提升。
在 Mark Callaghan 的性能横向对比（sysbench 吞吐场景） 中，可以看到五年前 PG 11 与 MySQL 5.6 的性能比值（蓝），与当下 PG 16 与 MySQL 8.0.34 的性能比值（红）。PostgreSQL 和 MySQL 的性能差距在这五年间拉的越来越大。
几年前的业界共识是 PostgreSQL 与 MySQL 在简单 OLTP CRUD 场景下的性能基本相同。然而此消彼长之下，现在 PostgreSQL 的性能已经远远甩开 MySQL 了。PostgreSQL 的各种读吞吐量相比 MySQL 高 25% ～ 100% 不等，在一些写入场景下的吞吐量更是达到了 200% 甚至 500% 的恐怖水平。
MySQL 赖以安身立命的性能优势，已经不复存在了。
无可救药的隔离等级
如果只是性能不好，总归还有办法来优化修补。但如果是正确性出了问题，那真就是无可救药了。《》一文指出，在正确性这个体面数据库产品必须的基本属性上，MySQL 的表现一塌糊涂。
权威的分布式事务测试组织JEPSEN研究发现，MySQL 文档声称实现的可重复读/RR隔离等级，实际提供的正确性保证要弱得多 —— MySQL 8.0.34 默认使用的 RR 隔离等级实际上并不可重复读，甚至既不原子也不单调，连单调原子视图/MAV的基本水平都不满足。
MySQL 的 ACID 存在缺陷，且与文档承诺不符—— 而轻信这一虚假承诺可能会导致严重的正确性问题，例如数据错漏与对账不平。对于一些数据完整性很关键的场景 —— 例如金融，这一点是无法容忍的。
此外，能“避免”这些异常的 MySQL可串行化/SR隔离等级难以生产实用，也非官方文档与社区认可的最佳实践；尽管专家开发者可以通过在查询中显式加锁来规避此类问题，但这样的行为极其影响性能，而且容易出现死锁。
与此同时，PostgreSQL 在 9.1 引入的 可串行化快照隔离（SSI） 算法可以用极小的性能代价提供完整可串行化隔离等级 —— 而且 PostgreSQL 的 SR 在正确性实现上毫无瑕疵 —— 这一点即使是 Oracle 也难以企及。
李海翔教授在《》论文中，系统性地评估了主流 DBMS 隔离等级的正确性，图中蓝/绿色代表正确用规则/回滚避免异常；黄A代表异常，越多则正确性问题就越多；红“D”指使用了影响性能的死锁检测来处理异常，红D越多性能问题就越严重。不难看出，这里正确性最好（无黄A）的实现是 PostgreSQL SR，与基于PG的 CockroachDB SR，其次是略有缺陷 Oracle SR；主要都是通过机制与规则避免并发异常；而 MySQL 出现了大面积的黄A与红D，正确性水平与实现手法糙地不忍直视。
做正确的事很重要，而正确性是不应该拿来做利弊权衡的。在这一点上，开源关系型数据库两巨头 MySQL 和 PostgreSQL 在早期实现上就选择了两条截然相反的道路：MySQL 追求性能而牺牲正确性；而学院派的 PostgreSQL 追求正确性而牺牲了性能。在互联网风口上半场中，MySQL 因为性能优势占据先机乘风而起。但当性能不再是核心考量时，正确性就成为了 MySQL 的致命出血点。更为可悲的是，MySQL 连牺牲正确性换来的性能，都已经不再占优了，这着实让人唏嘘不已。
枯萎收缩的生态规模
对一项技术而言，用户的规模直接决定了生态的繁荣程度。瘦死的骆驼比马大，烂船也有三斤钉。MySQL 曾经搭乘互联网东风扶摇而起，攒下了丰厚的家底，它的 Slogan 就很能说明问题 —— “世界上最流行的开源关系型数据库”。
不幸的是在 2023 年，至少根据全世界最权威的开发者调研之一的结果来看，MySQL 的使用率已经被 PostgreSQL 反超了 ——最流行数据库的桂冠已经被 PostgreSQL 摘取。
特别是，如果将过去七年的调研数据放在一起，就可以得到这幅 PostgreSQL / MySQL 在专业开发者中使用率的变化趋势图（左上） —— 在横向科比的同一标准下，PostgreSQL 流行与 MySQL 过气的趋势显得一目了然。
对于中国来说，此消彼长的变化趋势也同样成立。但如果对中国开发者说 PostgreSQL 比 MySQL 更流行，那确实是违反直觉与事实的。
将 StackOverflow 专业开发者按照国家细分，不难看出在主要国家中（样本数 > 600 的 31 个国家），中国的 MySQL 使用率是最高的 —— 58.2% ，而 PG 的使用率则是最低的 —— 仅为 27.6%，MySQL 用户几乎是 PG 用户的一倍。
与之恰好反过来的另一个极端是真正遭受国际制裁的俄联邦：由开源社区运营，不受单一主体公司控制的 PostgreSQL 成为了俄罗斯的数据库大救星 —— 其 PG 使用率以 60.5% 高居榜首，是其 MySQL 使用率 27% 的两倍。
中国因为同样的自主可控信创逻辑，最近几年 PostgreSQL 的使用率也出现了显著跃升 —— PG 的使用率翻了三倍，而 PG 与 MySQL 用户比例已经从六七年前的 5:1 ，到三年前的3:1，再迅速发展到现在的 2:1，相信会在未来几年内会很快追平并反超世界平均水平。毕竟，有这么多的国产数据库，都是基于 PostgreSQL 打造而成 —— 如果你做政企信创软件生意，那么大概率已经在用 PostgreSQL 了。
抛开政治因素，用户选择使用一款数据库与否，核心考量还是质量、安全、效率、成本等各个方面是否“先进”。先进的因会反映为流行的果，流行的东西因为落后而过气，而先进的东西会因为先进变得流行，没有“先进”打底，再“流行”也难以长久。号称“最流行”的 MySQL，终究还是难敌时间的审判。
究竟是谁杀死了MySQL？
MySQL 曾经也辉煌过，但再精彩的演出也会落幕。
MySQL 正在死去 —— 更新疲软，功能落后，性能劣化，质量出血，生态萎缩，此乃天命，实非人力所能救也。但究竟是谁杀死了 MySQL，难道是 PostgreSQL 吗？Peter Zaitsev 在《》一文中控诉，Oracle 的不作为与瞎指挥最终害死了 MySQL；并在后续《》一文中指出了真正的根因：
MySQL 的知识产权被 Oracle 所拥有，它不是像 PostgreSQL 那种 “由社区拥有和管理” 的数据库，也没有 PostgreSQL 那样广泛的独立公司贡献者。不论是 MySQL 还是其分叉 MariaDB，它们都不是真正意义上像 Linux，PostgreSQL 这样由社区驱动的的原教旨纯血开源项目，而是由单一商业公司主导。
比起向一个商业竞争对手贡献代码，白嫖竞争对手的代码也许是更为明智的选择 —— AWS 和其他云厂商利用 MySQL 内核参与数据库领域的竞争，却不回馈任何贡献。于是作为竞争对手的 Oracle 也不愿意再去管理好 MySQL，而干脆自己也参与进来搞云 —— 仅仅只关注它自己的 MySQL heatwave 云版本，就像 AWS 仅仅专注于其 RDS 管控和 Aurora 服务一样。在 MySQL 之死上，云厂商也难辞其咎。
逝者不可追，来者犹可待。PostgreSQL 应该从 MySQL 上吸取教训 —— 尽管 PG 社区已经非常小心地避免出现一家独大的情况出现，但生态确实在朝着几家巨头云厂商作大垄断的不利方向发展。
—— 云厂商编写了开源软件的管控软件，组建了专家池，通过提供维护攫取了软件生命周期中的绝大部分价值，但却通过搭便车的行为将最大的成本 ——产研交由整个开源社区承担。
云上区——在数据库领域，我们已经在 MongoDB，ElasticSearch，Redis，以及 MySQL 上看到了这一现象，而 PostgreSQL 社区确实应当引以为鉴。
好在 PG 生态总是不缺足够头铁的人和公司，愿意站出来维护生态的平衡，反抗公有云厂商的霸权。例如，我自己开发的 PostgreSQL 发行版，旨在提供一个开箱即用、本地优先的开源云数据库 RDS 替代，将社区自建 PostgreSQL 数据库服务的底线，拔高到比云厂商 RDS PG 更高的水平线。
而另一个《》系列专栏则旨在扒开云服务背后的信息不对称，从而帮助公有云厂商更加体面，亦称得上是成效斐然。
尽管我是 PostgreSQL 的坚定支持者，但我也赞同 Peter Zaitsev 的观点：“如果 MySQL 彻底死掉了，开源关系型数据库实际上就被 PostgreSQL 一家垄断了，而垄断并不是一件好事，因为它会导致发展停滞与创新减缓。PostgreSQL 要想进入全盛状态，有一个 MySQL 作为竞争对手并不是坏事”。
—— 至少，MySQL 可以作为一个与鞭策激励，让 PostgreSQL 社区保持凝聚力与危机感，不断提高自身的技术水平，保持开放、透明、公正的社区治理模式，从而继续推动数据库技术的发展。
PostgreSQL 带着开源软件的初心与愿景继续坚定前进 —— 它将走上 MySQL 未走完的长路，写完 MySQL 未写完的诗篇，见到 MySQL 未见的世界，活成 MySQL 未曾活过的愿。在这，谨以一首《PG驶向云外，MySQL安魂九霄》，送给曾经的对手 —— MySQL。
PG驶向云外，MySQL安魂九霄
我那些残梦，灵异九霄
徒忙漫奋斗，满目沧愁
在滑翔之后，完美坠落
在四维宇宙，眩目遨游
我那些烂曲，流窜九州
云游魂飞奏，音愤符吼
在宿命身后，不停挥手
视死如归仇，毫无保留
黑色的不是夜晚，是漫长的孤单
看脚下一片黑暗，望头顶星光璀璨
叹世万物皆可盼，唯真爱最短暂
失去的永不复返，世守恒而今倍还
摇旗呐喊的热情，携光阴渐远去
人世间悲喜烂剧，昼夜轮播不停
纷飞的滥情男女，情仇爱恨别离
一代人终将老去，但总有人正年轻
References：OsChina，感谢原作者。