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内核做的优化。mysql下载什么版本的
根据市场占有率前三分析，我们选择的版本⾄少要⼤于等于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，多做测试。
了解更多数据库知识，点击原⽂链接：

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。