就在今天,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 语法错误不报错,而是直接隐式转换执行:
再比如这个,事务默认没有原子性:
做正确的事很重要,而正确性是不应该拿来做利弊权衡的。在这一点上,开源关系型数据库两巨头 MySQL 和 PostgreSQL 在早期实现上就选择了两条截然相反的道路:MySQL 追求性能而牺牲正确性;而学院派的 PostgreSQL 追求正确性而牺牲了性能。
在互联网风口上半场中,MySQL 因为性能优势占据先机乘风而起。但当性能不再是核心考量时,正确性就成为了 MySQL 的 致命出血点。更为可悲的是,MySQL 连牺牲正确性换来的性能,都已经不再占优了,这着实让人唏嘘不已。
数据库老司机
点一个关注 ⭐️,精彩不迷路
对 PostgreSQL 与 Pigsty 感兴趣的朋友
欢迎微信搜索 pigsty-cc加入 PGSQL 交流群
MySQL安魂九霄,PostgreSQL驶向云外
Oracle还能拯救MySQL吗?
Oracle最终还是杀死了MySQL!
MySQL性能越来越差,Sakila将何去何从?
用PG的开发者,年薪比MySQL多赚四成?
MySQL的正确性为何如此拉垮?
前MariaDB高管叛变至PG阵营
如何看待 MySQL vs PGSQL 直播闹剧
驳《MySQL:这个星球最成功的数据库》
PostgreSQL正在吞噬数据库世界
欢迎参加第十三届PG中国技术大会
让PG停摆一周的大会:PGCon.Dev参会记
PGCon.Dev 扩展生态峰会小记 @ 温哥华
PostgreSQL 17 Beta1 发布!牙膏管挤爆了!
为什么PostgreSQL是未来数据的基石?
PostgreSQL is eating the database world
技术极简主义:一切皆用Postgres
PostgreSQL:世界上最成功的数据库
PostgreSQL 到底有多强?
Pigsty v2.7:集异璧之大成,扩展尽入彀中
把数据库放入Docker是一个好主意吗?
数据库应该放入K8S里吗?
向量数据库凉了吗?
向量是新的JSON
数据库真被卡脖子了吗?
国产数据库到底能不能打?
国产数据库是大炼钢铁吗?
分布式数据库是伪需求吗?
EL系操作系统发行版哪家强?
基础软件到底需要什么样的自主可控?
中国对PostgreSQL的贡献约等于零吗?
Redis不开源是“开源”之耻,更是公有云之耻
PostgreSQL会修改开源许可证吗?
RDS阉掉了PostgreSQL的灵魂
PG生态新玩家ParadeDB
DBA会被云淘汰吗?