在Linux服务器上维护MySQL数据库时，随着业务对功能和安全补丁的需求提升，使用操作系统自带的包管理器进行版本升级是最常见也最稳妥的方式之一。CentOS、Rocky Linux等红帽系发行版通常使用yum（或新版本的dnf），而Ubuntu、Debian则使用apt。虽然两者都是解决依赖的包管理工具，但在仓库配置、升级流程和风险控制上有明显区别。本文将以MySQL 5.7升级到8.0为例，分别说明yum与apt的具体操作步骤和注意事项。
一、升级前的准备工作
无论使用哪种包管理器，升级MySQL之前都必须做好完备的备份。生产环境中，任何跳过备份的升级操作都是高危行为。建议先用mysqldump导出全部逻辑数据，或者直接物理拷贝数据目录，并确认当前配置文件my.cnf的内容已留存。
另外需要检查当前系统的发行版与MySQL版本，确认目标大版本是否受支持。例如MySQL 8.0不再允许某些在5.7中合法的SQL模式，部分老应用可能需要先改造代码。可以通过如下命令查看现有版本：
# 查看MySQL版本 mysql -V # 查看当前系统类型 cat /etc/os-release
在确认环境后，还应阅读官方发行说明，记录不兼容变更。只有完成这些准备，后续的yum或apt升级才不会因未知差异导致服务异常。
二、使用yum进行MySQL版本升级
1. 配置官方MySQL yum仓库
红帽系默认仓库中的MySQL版本往往较旧，直接yum update可能无法跨大版本。我们需要先禁用系统自带模块，并导入MySQL官方仓库。以CentOS 7为例，下载对应rpm包并安装，它会在/etc/yum.repos.d/下生成mysql-community.repo。
安装仓库包后，可用yum repolist查看是否启用正确的subrepository。如果之前启用了mysql57-community，需要改成mysql80-community。这一步很关键，否则yum依旧会拉取旧版本。
# 下载并安装MySQL官方仓库 wget https://dev.mysql.com/get/mysql80-community-release-el7-7.noarch.rpm yum localinstall mysql80-community-release-el7-7.noarch.rpm -y # 禁用旧版本仓库，启用8.0 yum-config-manager --disable mysql57-community yum-config-manager --enable mysql80-community # 刷新缓存 yum makecache
2. 执行升级与后处理
仓库切换完成后，直接用yum update升级服务器包。yum会计算依赖并替换旧二进制文件，但配置文件通常保留为my.cnf.rpmsave以防冲突。升级完毕后必须重启mysqld服务，并运行mysql_upgrade检查系统表结构兼容性。
如果启动失败，多半是配置文件中含有8.0已移除的参数，比如query_cache_type。此时应参考rpmsave文件逐项比对，删除不支持项后再启动。以下为升级与检查命令：
# 升级MySQL服务器 yum update mysql-server -y # 重启服务 systemctl restart mysqld # 升级系统表 mysql_upgrade -u root -p
yum的优势在于事务完整，一旦某步失败可整体回滚；缺点是对跨大版本时的配置迁移不够智能，需要人工介入核对参数。
三、使用apt进行MySQL版本升级
1. 更换apt源与密钥
Debian系默认源里的MySQL常被替换成MariaDB，若要原版升级需添加MySQL APT仓库。先下载deb配置包，运行后通过交互界面选择MySQL 8.0系列，它会在/etc/apt/sources.list.d/下写入mysql.list，同时导入GPG密钥到受信任密钥环。
由于新版apt要求密钥以文件形式存放于/etc/apt/trusted.gpg.d/，旧的内联密钥方式会报错。因此我们安装配置包后，需执行apt update验证能否正常拉取索引，若出现NO_PUBKEY错误就要手动补密钥。
# 下载MySQL apt配置包 wget https://dev.mysql.com/get/mysql-apt-config_0.8.24-1_all.deb dpkg -i mysql-apt-config_0.8.24-1_all.deb # 更新索引 apt update
2. 升级软件包与表结构
apt升级时默认会保留已有配置文件，并提示用户选择「保留当前配置」还是「安装维护者版本」。对于大版本跨越，建议先备份再选保留，待服务起来后再手动合并新参数。执行apt install mysql-server即可触发跨版本替换。
重启后同样要运行mysql_upgrade。Ubuntu系统还可能用mysql服务名而非mysqld，需注意systemctl单元名差异。示例流程如下：
# 升级MySQL apt install mysql-server -y # 重启服务（Ubuntu下一般为mysql） systemctl restart mysql # 升级系统表 mysql_upgrade -u root -p
apt的优点是依赖解析快、源切换方便；但若之前混用过MariaDB源，可能需先 purge 旧包避免文件冲突，这比yum处理得更严格。
四、yum与apt升级方式对比
从运维角度看，两者核心逻辑一致：换源、刷索引、升包、修配置、升表。但yum基于RPM的事务机制，在中断时可回退；apt则更依赖管理员在交互中做决策，灵活性高但容易因选错配置导致启动失败。
下面的表格列出了主要差异，便于在不同环境中制定升级预案：
| 对比项 | yum（RPM系） | apt（Debian系） |
|---|---|---|
| 仓库配置文件 | /etc/yum.repos.d/*.repo | /etc/apt/sources.list.d/*.list |
| 密钥管理 | rpm --import或仓库包自带 | trusted.gpg.d目录存放 |
| 配置冲突处理 | 生成.rpmsave保留旧文件 | 交互提示保留或覆盖 |
| 回滚能力 | 事务级回滚较强 | 需借助快照或手动降级 |
实际操作时，建议先在测试机用相同OS跑一遍流程，记录每条命令的输出。这样正式升级时，即使遇到GPG错误或依赖断链，也能对照测试记录快速定位。
五、常见误区与避坑建议
一个常见误区是认为执行完包升级就万事大吉，忽略了mysql_upgrade。在MySQL 8.0中，某些权限表结构变更若不升级，会导致用户无法登录。另一个误区是在my.cnf里保留了已废弃的变量，造成服务卡在启动阶段。
此外，不要直接在跨大版本时开启skip-grant-tables来强行启动，这虽能进服务但会让后续表升级更麻烦。正确做法是临时注释问题参数，启动后跑升级脚本，再逐步加回合规配置。保持数据目录权限归mysql用户，也是避免权限报错的基本功。
# 检查数据目录权限 ls -ld /var/lib/mysql chown -R mysql:mysql /var/lib/mysql
只要严格遵循备份、换源、升级、修参、升表这五步，并理解yum与apt在配置处理上的不同，MySQL版本升级完全可以做到可控、可预期，不影响线上业务连续性。