MySQL 数据库升级后如何防止性能下降

​

第一：MySQL 数据库为什么要升级，大概多久进行一次

首先 MySQL 的每个版本有相应的 Endlife 周期，现阶段 MySQL 的 Endlife 周期如下：

从上图来看，当前处在官方支持生命周期的版本是 MySQL 8.0, 其中 MySQL 5.7 处在 Extended Support 也就意味着只会做安全方面的更新，其它的方前端培训面不在处理，MGR 的很多特性就没在往 5.7 中合并。所以当前最佳的方式是升级到 MySQL 8.0。那么我们接来来聊一下多久进行一次升级。这块大概可以分成三种情况

a. 依据产品形态定位升级时间

b. 依据服务的性能指标及成本做决定

c. 依据于使用到的 MySQL 特性做决定

以上三点，如果从升级的必要性角度看，可以反过来看。如果从业务角度出发可以正着看。

我这里首先从业形态上描述一下，对于依据产品的形态定位升级时间可以这么理解，我给大家举一个例子，例如我经历的产品有：SNS， 邮件系统，彩票系统，IM，电商，支付，直播等相关业务。其中邮件系统就是一个非常特殊的业务，他对 DB 的依赖不是特别大，对于数据库的使用，只需要记录用户认证及邮件列表的一些信息，并发要求也不高，所以现在还有一些系统跑在 MySQL4.1 上还是运行的很好，很多系统已经超过 1500 天以上没有重启的都有。对于这类业务，基本没有升级的必要，对于 MySQL 依赖非常轻，只是简单的 CRUD 使用，升级并不能带来特别大的提升，反而增加了复杂度。

另一类业务属于高速增长的业务：SNS，彩票，IM，电商，支付，这种系统基本上对性能都有较强需求，好的性能意味着更好的用户体验。一般情况下这种业务建议是出现大版本更新可以升级，例如：MySQL 5.5 比 MySQL5.1 的性能好， MySQL5.6 比 MySQL5.5 的性能好，MySQL 5.7 又比 MySQL5.6 的性能好，MySQL 8.0 是功能丰富了很多对于开发，DBA 管理等方面都更加友好，而且如果你的硬件在 32 个 core 以上，也可以考虑升级到 MySQL8.0，如果硬件比较旧（cpu core 小于 32， 没有使用 ssd 以上的盘)也不能获取升级到 8.0 性能优势。

所以针业务形态定位这块一般建议是出现大版本更新，MySQL 大版本稳定后可以安排升级，通过时间间隔在 1-2 年的情况，另一类对数据依赖不大的业务，没遇到 Bug 也可以不用升级。

依据于服务的性能指标及成本做决定。从目前的经验来看 MySQL8.0，MySQL 5.7 的性能基本是吊打以前的版本，同样对资源的利用率也更高了，所以在 MySQL 5.7， MySQL 8.0 这两个版本可以说 MySQL 非常优秀的版本。对于这两个版本推荐使用 MySQL 8.0，如果条件（机器资源烂）也可以考虑使用 MySQL 5.7。通常情况下公司的业务也在发展，MySQL 新版本的升级总可以带来正向的促进，也促进公司的技术人员更加关注新知识的发展。

这里我们再来看看使用到 MySQL 的特性来决定，也是最重要的一点。使用到特性主要是指的：CRUD 的使用，复制，MGR 等三个方面，对于 CRUD 的更关注在 MySQL 的 SQL 解析，连接数，Buffer 的优化，索引的优化这块基本是随着版本的升高，都会有相应的优化；接下说一下复制，目前 MySQL 的复制可以说到 MySQL5.7 才算真正处理的完美，所以使用到复制功能的人，使用 MySQL 的最低版本应该是 MySQL5.7 并开启基于 writeset 的并行复制，这个特性在 MySQL8.0 中优先实现，后来合并到 MySQL5.7 中；接下来说一下 MGR 这个特性，如果你已经使用到 MGR，你是属于技术激进派的，同时也恭喜你现在 MySQL8.0.22 及以后的 MGR 非常的稳定了，可以使用了。但 MGR 还算是 MySQL8.0 中比较新一个特性，每个小版本中也会有一些特性的更新及 Bug 修复，所以建议使用 MGR 的朋友，如果现在你还是使用 8.0.23 以前的版本，可以考虑升级到 8.0.23 后版本。对于使用比较新的特性，需要关注每个小版本，如果小版本中有重要的修复，也可以安排小版本出来测试，一个月左右进行升级，这个在企业版本客户中特别常见。

第二： 升级前升级中升级后关键事项以及需要业务应用侧配合的事项

数据据库升级是一个全公司需要一起行动的工作。在这里我们可以先把工作，分为升级前， 升级中，升级后的关键事项及业务应用侧需要配合的事项。

升级前准备及相关工作：

1. MySQL 的版本升级必要必能对比。功能性验证，bug 验证，性能验证

2. 最优配置文件确定

3. 功能环境验证新版本，同时给开发人员讲解新版本的特性及使用上注意事项

4. 带业务（核心业务的）性能测试，这个步骤需要按生产环境部署

5. 确认可以升级停业务的时间，采用不同的升级方案

6. 升级后 checklist 制定

7. 预期升级后的对比点

升级中执行及相关工作：

1. 当晚工作分配列表及时间规划

2. 应用对于 DB 服务中断的处理策略，好的升级方案，可能只需要 DB 中断服务在秒级别以下，在升级方案中详讲。

3. 升级执行前停止数据库对应系统的报警及报警升级

4. 升级中业务进行日志观察

5. 数据库 OPS，DML 和升级前进行对比

6. 新上线的 DB 系统加入监控报监控系统

7. 回退系统部署方案及知会开发

升级后收尾及相关工作：

1. 升级后的运行情况报告

2. 开发侧数据库相关日志收集及对比

3. 回退系统下线

从上面策略上看可以说把更多的工作压到前面来做，特别是升级前的的准备工作也占用大量的时间的工作。在这个环节上 DBA 的测试工作也比较多。

对于升级方案，涉及到产品功能验证，bug 验证，性能验证，升级方案的确定等。 凡是涉及到升级可能就会涉及到 MySQL 的性能有提升，或是遇到重要 Bug。这块其实有一个技能被大家忽略了：就是官方发布的 mrr test 测试。做为我们个人，可以通过把低版本的 mrr test 放到目标版本中测试，可以对比一下两个版本在同样的配置下 mrr test 跑完的时间，及具体 case 跑完的时间，通过该测试从 DBA 角度可以评估出来现在使用的版本和将要升级的目标版本间的差距。该操作可以反过来进行，把高版本的 mrr test 放到低本下跑一次，可以看看具体修到的 Bug 及对应的东西，友情提示，该工作需要一个强劲的机器，同时是一个比较花时间的过程。建议认真阅读 change log 找对应的修复，测试对应修复关心的问题即可。接下来可以通过 sysbench, mysql-tpcc 这类工具对两个版本压测试，得出来一个较佳的配置文件， 同时得出来两个版本在 Bug，性能上全方面数字量化升级指导意见。后续就可以交给功能测试和性能测试的同事介入了。

第三： 如何规划 MySQL 升级方案

对于升级案最佳的方案就是少停机，尽量减少对业务的影响。这里给一个兼顾回退方案的方案的升级方案，也是我认为比较稳妥的一个升级方案。利用复制技术升级。大致步骤如下：

在第 2 步骤时，可以通过添加一个从库，只用于数据同步，确认没有问题后可以入 Proxy 或是 DNS 中对外提供服务，遇到问题可以立即下线。

第 3 步，可以把原来其中的一个 slave 也升级到新版本上。

第 4 步，可以把所有读请求转到从上库上，原始的从库版本不用对外提供服务；观察俩个新的 slave 对外服务的情况。

第 5 步， 通过 HA 切换把原来的 Old Master 切换成从库，并提供对外服务，确认没有问题时把原来最后一个从库也升级到最新版本

第 6 步，把原来的版本 slave 停止对外服务，全部使用新版本对外提供服务。

该升级方案的好处，基本上可以白天用于数据准备工作，新节点创建，老节点替换等，在业务低峰期，也只是更新一下 Proxy 配置或是走一个 HA 切换，相对来讲对外影响非常小，回退处理也相当容易。

这块可以使用到的技术：

proxy 推荐：ProxySQL

HA 切换推荐：Orchestrator， Xenon

如果不想用 Proxy 那么 Zookeeper， Consul，etcd 也可以使用。

第四：如何规划 MySQL 升级回退方案

一个好的升级方案是自带回退，进可攻，退可守，例如上面的方案，就属于一个优秀的升级方案。 如果基于上述方案中进行，对于任何一个失败点，在第 6 步前，都可以轻易回到旧版本中对外提供服务，这个过程可能就是需要多浪费一台机器，也可以说是一个实例，在多实例环境，这种方案处理着非常容易。在我处理的客户环境通常建议他们全局各每一种的端口号是唯一的，所以通过多实例来处理比容易上手。

第五： 怎么避免 MySQL 升级后造成性能下降

大多数情况下 MySQL 升级后会有一定的性能提升，但也不可避免出现性能下降的现象。例如我遇到性能下降问题：MySQL 升级后某个业务超时严重， 当时的问题我们在升级数据时，开发也更新了应用，造成大家对于这个问题有点不好对比。所以尽量在升级时尽量业务侧的变更，引入较少的变量。对于升级后性能下降的避免方法，我最大的经验是一定要做好：性能测试，基本业务的性能测试，也可以说是一个全链路性能测试采样对比。

第六： 升级后性能下降问题诊断及性能优化解决思路

这个问题可以说是 DBA 工作中一个重点任务，也是一个非常复杂的问题。这里尽量假设时你已经保证性能测试，功能测试，带业务的功能测试都过了，在功能环境，性能环境确认新版本是有性能提升。最后上线，又出现新性能问题。 那么这个时间出现性能问题，可以通过对比 sys.statement_analysis 中的内容，看看是不是有和功能环境不一致的 SQL，另外也可以结合慢日志查看和以前的慢日志内容是不是一致，通过这两条基本上很容易对比出来性能下降的点。如果使用的 ProxySQL 也可以在 ProxySQL 中查看每个 SQL 的响应时间分布，对于性能问题排查还是比较容易。通过对比 SQL 样品表，比较容易找到原因。另一类问题遇到统计信息失效，show processlist 显示大量的 Statics 相关的信息，可以通过收集索引信息或是重新整理表空间清除；还有一个类是字符配置错误，造成索引失效。

第七：总结

到今天为止 MySQL 技术非常成熟，很多公司已经把 MySQL 也定位在微服务架构中的一个持久化服务，使用上比较容易上手。但对于升级这个环节，如果为了减少问题，尽可能花更多的时间去测试。同样需要慢慢完善数据库的架构，这样后面升级管理方面也更加友好。

升级中遇到问题是否可以快速定位，我觉得有两方面的能力，一方面是 MySQL DBA 的基本技能能力，另一方面是对业务熟的程度，这个也是我在面试中或是同事考核中比较看重的，例如：核心系统，核心表是哪些，核心 SQL 是哪些，大概每天的请求量分布是什么样，高峰期核心库的 DML 操作量是多少，整个业务系统大概有多少条唯一的 SQL，如果能对这些问题清楚的了解，那么对整个系统的性能问题的排查就相当容易了。也可以说升级是一个对全体人员要求比较高的工作，也是一个需要配合的工作，同时也希望把 80%的时间花在测试上。真正的升级，可能利用自动工具，也可以非常快的完成。

原创作者：吴炳锡

​