MySQL新版恶性Bug，表太多就崩给你看！

就在今天，MySQL 8.0.38 以上的版本又爆出来一个恶性 Bug —— 如果数据库里有超过 1万张表，那么重启的时候 MYSQL 服务器会直接崩溃！

在上一篇《MySQL is dead, Long live PostgreSQL》，我们聊到了 MySQL 新版本的几个问题 —— 功能更新越来越拉垮敷衍，QPS 吞吐性能随版本更新越来越差。但我确实没有想到，MySQL 新版本的正确性与质量也越来越烂了。难道真的是 Oracle 嫌云厂商白嫖，彻底在 MySQL 开源版上摆烂了吗？

一个数据库里 1万张表并不是很罕见的情形 —— 特别是用了一些分表方案，或者是会动态创建表的应用中。而 Server 直接 Crash 显然是可用性故障（A）里最严重的一类情形。详情请参考 Percona 工程师 Ticket：

https://perconadev.atlassian.net/browse/PS-9306

如果你的 MySQL 版本是 8.0.38, 8.4.1 或者刚刚新发布的 9.0.0 ，那么就很不幸地中招了。

老实说，MySQL 最近确实是太拉垮了…… 不论是在功能上，还是性能上，还是正确性上，都是越来越差了：

缓慢空洞的功能更新

MySQL 官网发布的 "What's New in MySQL 9.0"^[5] 介绍了 9.0 版本引入的几个新特性，而 MySQL 9.0 新功能概览 一文对此做了扼要的总结：

在更新的六个特性中，后四个都属于无关痛痒，一笔带过的小修补，而前两个 向量数据类型 和 JS存储过程 都拉垮无比：

MySQL 9.0 的向量数据类型只是 BLOB 类型换皮 —— 只加了个数组长度函数，而这种程度的功能，28年前 PostgreSQL 诞生的时候就支持了。纯粹就是为了 Oracle 云版本的 Heatwave 准备的。

而 Javascript 存储过程支持直接就是一个 企业版独占特性，开源版不提供 —— 同样的功能，13年前 的 PostgreSQL 9.1 就已经有了。

时隔八年的 “创新大版本” 更新就带来了俩 “老特性”，一个应该有大量 Breaking Change 的“创新大版本更新”，不是糊弄人的摆烂特性，就是企业级的特供鸡肋，一个大版本就连鸡零狗碎的小修小补都凑不够数。“创新”这俩字，在这里显得如此辣眼与讽刺。

越新越差的性能表现

缺少功能也许并不是一个无法克服的问题 —— 对于一个数据库来说，只要它能将自己的本职工作做得足够出彩，那么架构师与DBA总是可以多费些神，用各种其他的数据积木一起拼凑出所需的功能。

MySQL 曾引以为傲的核心特点便是性能 —— 至少对于互联网场景下的简单 OLTP CURD 来说，它的性能是非常不错的。然而不幸地是，这一点也正在遭受挑战：Percona 的博文《Sakila：你将何去何从^[18]》中提出了一个令人震惊的结论：

MySQL 的版本越新，性能反而越差

根据 Percona 的测试，在 sysbench 与 TPC-C 测试下，最新 MySQL 8.4 版本的性能相比 MySQL 5.7 出现了平均高达 20% 的下降。而 MySQL 专家 Mark Callaghan 进一步进行了详细的性能回归测试^[19]，确认了这一现象：

MySQL 8.0.36 相比 5.6 ，QPS 吞吐量性能下降了 25% ～ 40% ！

尽管 MySQL 的优化器在 8.x 有一些改进，一些复杂查询场景下的性能有所改善，但分析与复杂查询本来就不是 MySQL 的长处与适用场景，只能说聊胜于无。相反，如果作为基本盘的 OLTP CRUD 性能出了这么大的折损，那确实是完全说不过去的。

ClickBench：MySQL 打这个榜图什么呢？

Peter Zaitsev 在博文《Oracle最终还是杀死了MySQL^[20]》中评论：“与 MySQL 5.6 相比，MySQL 8.x 单线程简单工作负载上的性能出现了大幅下滑。你可能会说增加功能难免会以牺牲性能为代价，但 MariaDB 的性能退化要轻微得多，而 PostgreSQL 甚至能在 新增功能的同时显著提升性能”。

MySQL的性能随版本更新而逐步衰减，但在同样的性能回归测试中，PostgreSQL 性能却可以随版本更新有着稳步提升。特别是在最关键的写入吞吐性能上，最新的 PostgreSQL 17beta1 相比六年前的 PG 10 甚至有了 30% ～ 70% 的提升。

在 Mark Callaghan 的 性能横向对比^[22] （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正确性竟如此拉垮？^[23]》一文指出，在正确性这个体面数据库产品必须的基本属性上，MySQL 的表现一塌糊涂。

权威的分布式事务测试组织 JEPSEN^[24] 研究发现，MySQL 文档声称实现的 可重复读/RR 隔离等级，实际提供的正确性保证要弱得多 —— MySQL 8.0.34 默认使用的 RR 隔离等级实际上并不可重复读，甚至既不原子也不单调，连 单调原子视图/MAV 的基本水平都不满足。

MySQL 的 ACID 存在缺陷，且与文档承诺不符 —— 而轻信这一虚假承诺可能会导致严重的正确性问题，例如数据错漏与对账不平。对于一些数据完整性很关键的场景 —— 例如金融，这一点是无法容忍的。

此外，能“避免”这些异常的 MySQL 可串行化/SR 隔离等级难以生产实用，也非官方文档与社区认可的最佳实践；尽管专家开发者可以通过在查询中显式加锁来规避此类问题，但这样的行为极其影响性能，而且容易出现死锁。

李海翔教授在《一致性八仙图》论文中，系统性地评估了主流 DBMS 隔离等级的正确性，图中蓝/绿色代表正确用规则/回滚避免异常；黄A代表异常，越多则正确性问题就越多；红“D”指使用了影响性能的死锁检测来处理异常，红D越多性能问题就越严重；不难看出，这 MySQL 出现了大面积的黄A与红D，正确性水平与实现手法糙地不忍直视。

当然，MySQL 的正确性问题并不仅仅是这些 —— 还有一些非常离谱的“特性”。比如这个，Update 语法错误不报错，而是直接隐式转换执行：