MySQL8.0版本选型建议

前言：MySQL 8.0 第一个GA（General Availability）版本（正式、可用于生产的版本）于2018/4/19发布至今已有3年。8.0是一个全新的版本，增加了数百项功能新特性，重构了SQL解析器，在性能和安全性上越来越向商业数据库靠拢。5.7版本优越的稳定性和性能已经广泛应用，如今性能、安全性和众多企业级特性提升让我们思考是否该使用8.0版本。本文从以下几个方面来了解一下。

01

官方补丁维护生命周期管理

如上图所示，这是oracle官方对软件产品的生命周期管理，MySQL被收购后也适用于该管理方式。

正如表格中所示，5.6今年就将结束支持，5.7版本在2023年结束其扩展支持，官方将不再发布补丁维护，而8.0的支持将持续到2026年。

建议使用8.0，逐渐累积新版本经验为后续升级做准备。

02

MySQL8.0 GA 以来bug修复统计

该表格是8.0版本发布可用于生产的正式版本以来所有bug的修复统计情况。
从表格中可以看出总bug修复数量逐渐收敛中。
我们最为关心的Innodb和复制相关的bug修复也是逐渐稳定下来。
但梳理8.0每个小版本可以发现，每个小版本都会推出许多新功能，这也可能造成小版本之间差异过大和带来新的稳定性问题。

例如，当时8.0.20发布时，修改了redo格式，导致常用的物理备份工具xtrabackup不支持，两个月后xtrabackup支持该redo格式，但是这种基础功能还是需要时间检验。
整个8.0主要是对group replication的不断完善，同时还推出了Innodb Cluster和ReplicaSet 高可用方案，所以如果需要使用MGR请优先选择8.0。

如果需要用到新特性来解决工作中的痛点：比如hash join、窗口函数以及在线迅速加字段的特性，还有在高并发下性能的提升也是选择8.0的重要原因。

03

各大金融企业如何选择8.0版本

目前已经有不少金融机构在8.0上做出尝试，他们对于版本的选择是十分谨慎的，一般正式发布一年半之后才开始使用
大多数版本选择都是从8.0.18开始，比如某五大行中两家机构选择8.0.18入坑,某些股份制银行则是选择8.0.18、8.0.20和8.0.21。
大多数的选择策略均为当时的最新版本，版本集中在8.0.18~8.0.21。
选择最新的版本会修复前面版本出现的重大bug。
比如，最近5月11日发布了新版本，距离上个版本不到一个月的时间，不太符合常规3个月一个小版本的规律，查看release notes紧急修复3个bug。

以前关于选择软件版本都有一个默认规矩，为了规避风险都会选择次新版本的方案，这也是有一定道理的。

毕竟次新版本出来几个月了，经过验证一般不会有重大问题。

但是这个经验在MySQL8.0 版本选择上也不是特别是适合，比如当前最新的版本是8.0.25，而选择次新的8.0.24刚好是有重大问题的。

有人会说使用最新版本新的功能可能会带来新的稳定性，但是我们常用的功能基本集中在Innodb、复制、分区表、优化器上，只要这些基础功能没有重大变化，那么这些基础功能早期发现的小问题在新的版本基本都会得到修复。
所以，不管是选择次新还是最新版本都可能遇到问题，关键还是关注每个版本的release notes所记录的修复问题，重大变化和新增功能，是否影响自己使用的功能。
其实我们也可以以公有云厂商采用基于社区版哪个版本来提供的RDS服务作为参考。
如阿里云RDS根据文档中版本信息是基于社区版8.0.22，华为云文档中显示内核基于8.0.20，腾讯云基于8.0.18内核做的优化。
根据市场占有率前三分析，我们选择的版本至少要大于等于8.0.22。
以下版本在选择的时候需要注意：
要注意8.0.19这个版本的安全漏洞问题，大家最好避免这个版本以免被安全软件扫到。

8.0.23版本修复了FTWRL影响其他会话执行show table status,可能影响类似mysqldumper等备份工具，所以需要用到此功能最好大于等于8.0.23。
理论上我们应该选择最新的版本，至少概率上更加稳定，使用开源软件还是需要多测试多踩坑找到自己的使用边界。

04

总结

基于以上MySQL官方维护周期，8.0持续到2026年。
MySQL基础功能关于Innodb引擎和复制的bug修复是逐渐收敛，版本稳定性逐渐加强。
调研众多金融机构公司，8.0被逐渐使用，更具企业级的功能和安全性得到青睐。
综上所述，8.0使用没有问题，如果使用社区版请使用最新的，多关注每个版本的release notes，多做测试。