低停机！一文搞定MySQL生产环境平滑升级

核心结论速览：生产环境升级首选主从滚动升级（最小化停机）或原地升级（小版本稳妥路径）；必须完成双重备份+测试环境演练+回滚预案三大前置动作；升级后需验证数据完整性、业务兼容性与性能指标，全程在业务低峰期执行并预留2倍预估时间用于回滚MySQL。

本文以MySQL8.0为例来进行升级，MySQL5.7-MySQL8.4等版本也可参考此方法进行升级。

一、为什么要升级到最新版？

当前MySQL8.0的最新版是MySQL8.0.45，作为2026年1月发布的最新稳定版，主要带来以下价值：

• 安全加固：修复多个高危漏洞，强化数据加密与访问控制（每隔一段时间就会有新漏洞被挖掘出来，解决的最好方法就是升级）
• 性能优化：提升InnoDB并发处理能力，优化大表查询性能
• Bug修复：解决了8.0早期版本中的多个稳定性问题
• 功能增强：新增监控指标，改进错误日志输出，便于问题排查

其中安全加固是推动升级的主要原因，因为很多企业对数据库中高危零容忍；在做等保认证时，必须解决中高危漏洞。

二、升级前的核心准备

1. 备份及备份有效性验证

必须进行一次全量备份（物理备份、逻辑备份均可），以免有异常时有原始版本的数据兜底。

注意：物理备份时需要选择对应的xtrabackup的版本。

备份完毕后还必须进行一次备份文件有效性验证，必须保证备份可恢复。这个很多人都容易忽略，只关注备份，不考虑备份文件是否可以恢复。

# 以下是简化后的备份恢复命令
# 验证物理备份
 xtrabackup --prepare --target-dir=/backup/mysql_full  
 # 验证逻辑备份 
 mysql -u root -p -e "source /backup/mysql_all.sql" test_db

关于备份恢复、可以参考历史文章。

转战MySQL Shell！数据库备份新姿势，轻松搞定备份操作！

MySQL数据备份与恢复(二) -- xtrabackup工具

MySQL数据备份及还原（一）

深入面试场景：为什么XtraBackup比mysqldump更适合生产环境？

2. 环境与配置检查

选择对应版本的mysql shell进行升级前兼容性扫描（强烈推荐），当前版本是MySQL8.0.45

# 使用MySQL Shell的升级检查工具（8.0.26+才支持）
mysqlsh
\connect root@localhost:3308
util.checkForServerUpgrade()

低版本可以用mysqlcheck 检查

# 检查所有数据库的表是否有升级隐患 
mysqlcheck -u root -p --all-databases --check-upgrade

3. 配置文件清理

为了避免配置文件中有已被新版本废弃的“僵尸参数”影响后续数据库启动，在升级前也需要检查一下配置文件。

# 查找并移除8.0中已废弃的参数
grep -i "query_cache\|no_auto_create_user\|secure_auth" /etc/my.cnf
# 注释或删除以上参数，避免启动失败

另外也需要对重点参数进行确认：

• lower_case_table_names：升级后不可修改，确保与当前设置一致MySQL
• default_authentication_plugin：8.0默认caching_sha2_password，需确认应用兼容性(升级客户端或修改密码插件）
• innodb_fast_shutdown：建议设置为0（完整关闭），避免升级时数据损坏

4. 测试环境演练（重点，必须执行）

搭建与生产环境完全一致的测试环境（硬件、配置、数据量），执行完整升级流程，包括备份、升级、验证、性能测试，没有问题后还要重点进行如下测试：

• 进行一次递归测试，尽量覆盖所有业务功能
• 存储过程、函数、触发器兼容性
• 应用连接与认证方式
• 复杂查询性能对比
• 备份恢复流程有效性

三、升级方式选择

根据场景决定改用哪种方式进行升级，生产环境推荐使用主从滚动升级的方式。

四、原地升级详细步骤

逻辑升级比较简单，本次就不做演示了。生产环境相同大版本基本选择原地升级的方式。本次因为是从MySQL8.0.39升级到MySQL8.0.45，就使用原地升级的方式。主从滚动升级的方案每个节点的升级也优先选择原地升级。

1. 下载并准备安装包

从官网下载安装包。https://dev.mysql.com/downloads/mysql/

例如本次的版本

上传至服务器后，解压，并替换原先的软链接

调整后

2. 优雅停机与备份确认

登录数据库进行优雅停机，避免使用kill方式停机。

mysql> show global variables like 'innodb_fast_shutdown';
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| innodb_fast_shutdown | 1     |
+----------------------+-------+
1 row in set (0.01 sec)

mysql> set global innodb_fast_shutdown=0;
Query OK, 0 rows affected (0.00 sec)

mysql> shutdown;
Query OK, 0 rows affected (0.00 sec)

注意检查备份，确认在此执行已经做过全量备份及备份有效性验证。

3. 启动数据库并验证升级

在开始敲命令之前，我们需要先对齐一个关键的技术认知，这能帮你省去很多不必要的麻烦。

MySQL8.0.16是一个分水岭。

过去（8.0.16之前）：升级完软件包后，你必须手动运mysql_upgrade工具来更新系统表。

现在（8.0.16及之后）：mysql_upgrade工具已被废弃。升级逻辑直接集成到了mysqld进程中。当你用新版本的二进制文件启动数据库时，它会自动检测并升级数据字典和系统表。

简单来说：现在的升级，只要软件包换得对，重启即升级。

启动完毕后，登录数据库，查看升级后的版本（注意一定要登录数据库而不是看客户端版本（亲眼见过有人看客户端版本来判断数据库版本））

查看数据库日志，也能看到对应的升级记录。

五、主从滚动升级：最小化停机方案（推荐）

适合已部署主从复制的生产环境，停机时间仅为切换主从的秒级时间。

1. 升级所有从库

# 停止从库复制
STOP SLAVE;  # MySQL 8.0.22前
STOP REPLICA;  # MySQL 8.0.22后
# 按照原地升级步骤升级从库（关闭→升级→启动）
# ... 重复原地升级步骤 ...
# 启动复制并验证
START REPLICA;
SHOW REPLICA STATUS\G  # 确保Seconds_Behind_Source为0

2. 主从切换

# 1. 主库设置为只读
SET GLOBAL read_only=ON;
# 2. 等待所有从库同步完成
SHOW REPLICA STATUS\G  # 确认所有从库已追上主库
# 3. 应用切换到从库（新主库）
# 修改应用连接字符串，指向新主库IP/端口

3. 原主库作为从节点添加至集群中

升级从库后，不建议立即升级原主库，而是将原主库线作为从节点加入集群，以免出现不兼容问题。届时，可以立即秒极恢复。

4. 升级原主库

线上平稳一段时间后，可以将原主库按照原地升级步骤进行升级，这样就完成了整个集群节点的升级。

5. 升级后持续监控

升级完毕后，注意持续监控数据库的运行情况，尤其是稳定性及性能）。

完整的步骤如下：

六、总结

升级MySQL8.0到最新版，核心在于“备份先行，替换二进制，重启即升级”。

只要做好全量备份，并严格按照替换软链接、修正权限的步骤操作，这通常是一个低风险、高收益的运维动作。毕竟，新版本的性能优化和Bug修复，是数据库稳定运行的最佳保障。

最后再次，提醒生产环境升级务必选择业务低峰期，并预留2倍预估时间用于处理意外情况。升级过程中保持冷静，遇到问题优先执行回滚预案，避免数据丢失。

最后祝大家的数据库升级都很顺利，0故障！