20年未修的 MySQL 漏洞，导致用户投奔PostgreSQL

一个早在2005年6月就被提交的 MySQL 漏洞，如同一个顽固的“钉子户”，至今仍未被修复，而它被标记的严重性等级为“S2（严重）”。这一状况，让围绕这个开源数据库管理器的社区陷入了既觉得好笑又深感绝望的复杂情绪中。

这个被编号为 Bug #11472 的漏洞，其描述为“在更新/删除外键后未执行触发器”。在数据库的世界里，触发器就像是忠诚的卫士，是一段代码，当特定表中发生插入、更新或删除事件时，它会自动运行，主要职责是强制维护数据的完整性。然而，这个漏洞却表明，如果指定表因为与其他表存在关联关系而被间接更新，那么触发器就不会执行，这无疑给数据的完整性埋下了一颗“定时炸弹”。

在漏洞发布后不久，MySQL 团队曾轻描淡写地评论说这是一个“已知问题”，并且信誓旦旦地表示“我们将在5.1中修复这个问题”。但现实却很残酷，这个承诺就像一张无法兑现的空头支票，漏洞至今未被修复。尽管在手册中有所记录，明确指出“级联的外键操作不会激活触发器”，但这并没有改变漏洞依然存在的事实。

开发者们对这个漏洞的态度可谓是又急又气。有开发者在评论中毫不留情地指出该问题“严重威胁到ACID/完整性”。ACID 可是数据库的四大基石，分别代表原子性、一致性、隔离性和持久性，这个漏洞无疑是对这四大基石的公然挑战。到了2015年，又有开发者无奈地表示：“我们尝试在级联删除上实现触发器后开始遭受这个问题。请尽快修复。”可 MySQL 团队似乎对此置若罔闻。

时间来到2020年，一位年轻开发者幽默又无奈地提到：“这个bug比我年纪还大。”这句看似玩笑的话，背后却藏着多少开发者的心酸与无奈。

这个漏洞的影响是巨大的。在2023年，一位开发者直言：“我们几年前就放弃了MySQL——这个bug就是压垮骆驼的最后一根稻草。我们需要一个自定义账户平台的数据完整性。”对于企业来说，数据的完整性就如同生命线，一旦受到威胁，后果不堪设想。

MySQL 的命运在2010年发生了重大转折，它被甲骨文收购，成为了 Sun Microsystems 的一部分。虽然这个特定的错误发生在甲骨文参与之前，但它还是被一些人看作是甲骨文疏忽管理的证据。也有人提出另一种观点，认为像这样长期存在且有记录的缺陷，最好还是保持原样，以防某个应用程序已经依赖它。不过，从实际情况来看，这种可能性似乎并不大。

MariaDB 作为 MySQL 的一个分支，诞生于 Oracle 收购时期，它也未能摆脱这个漏洞的困扰，同样将其标记为“未解决”。

在 Reddit 上，关于这个漏洞引发了一场激烈的讨论。有人争论触发器对于数据库完整性是否真的是最佳实践，毕竟数据库管理领域的方法和观点多种多样。但另一个更为常见的回应是：“解决方法不是不使用MySQL，而是使用一个合理的关系型数据库。”而在众多替代选择中，PostgreSQL 成为了最热门的人选。甚至有人调侃道：“在这一点上它是一个特点。”这种无奈的调侃，也反映出开发者们对 MySQL 漏洞的无奈和失望。

从 DB-Engines 排名来看，MySQL 虽然依旧保持着一定的热度，是仅次于 Oracle 的第二大最受欢迎的数据库管理系统，Microsoft SQL Server 则排在第三位。然而，近年来 MySQL 的使用趋势却呈现出明显的下降态势，而 PostgreSQL 则如同一颗冉冉升起的新星，呈上升趋势。不过，需要指出的是，这个排名是基于提及和职位招聘数据，并非实际使用数据，所以也不能完全据此下定论，但它确实从侧面反映了 MySQL 正在逐渐走向衰落。

去年，与 MySQL 合作多年的 Percona 的 Peter Zaitsev 告诉《Register》，“MySQL似乎在性能工程部门被忽视了多年”，并且他还表达了自己的观点，认为 Oracle 通过将重要的新特性专用于基于云的 Heatwave 来边缘化开源 MySQL。这一系列的情况，都让 MySQL 的未来充满了不确定性。