在 Debian 和 Ubuntu 系统中，使用 MySQL 官方提供的 APT 存储库来升级 MySQL，是一种比直接下载二进制包更规范、更易于维护的做法。它能让系统包管理器接管版本依赖、配置文件保护和升级流程，降低人为操作失误带来的风险。
为什么选择 MySQL APT 存储库升级
很多老系统最初是用系统自带源安装的 MySQL，版本往往滞后。当业务需要新特性或安全补丁时，系统源里并没有对应版本。此时若手动编译或覆盖安装，很容易破坏原有依赖关系，甚至导致服务无法启动。MySQL APT 存储库由 Oracle 官方维护，提供了与发行版适配的 deb 包，能够无缝接入 apt 体系。
通过 APT 存储库升级，最大好处是流程标准化。包管理器会自动处理文件替换、服务重启以及必要的数据字典升级。如果升级失败，也可以利用 apt 的缓存机制回退到旧版本包。此外，存储库支持在同一个源中切换 MySQL 系列，比如从 5.7 切换到 8.0，无需重新配置复杂的安装脚本。
配置 MySQL APT 存储库
第一步是下载官方配置包，它会帮我们写入源列表和 GPG 密钥。以 Debian 11 为例，可以从官网获取 mysql-apt-config 的 deb 文件，用 dpkg 安装后，运行交互界面选择需要的 MySQL 版本系列。
如果希望非交互批量部署，也可以手动创建源文件。下面示例直接写入一个固定的 MySQL 8.0 源，并导入公钥，适合自动化运维场景。
# 导入 MySQL 官方 GPG 密钥 sudo apt-get install -y gnupg wget -O /tmp/mysql_pubkey.asc https://repo.mysql.com/RPM-GPG-KEY-mysql-2022 sudo gpg --dearmor -o /usr/share/keyrings/mysql-archive-keyring.gpg /tmp/mysql_pubkey.asc # 手动写入 APT 源（以 Ubuntu 22.04 为例） echo "deb [signed-by=/usr/share/keyrings/mysql-archive-keyring.gpg] https://repo.mysql.com/apt/ubuntu jammy mysql-8.0" | sudo tee /etc/apt/sources.list.d/mysql.list # 更新索引 sudo apt-get update
配置完成后，执行 apt-cache policy mysql-server 可以确认候选版本是否已经变成存储库中的新版本。这一步非常关键，能避免实际升级时仍拉取系统旧包。
执行升级操作
在确认源无误且已备份数据后，就可以用 apt-get 执行升级。推荐先升级客户端工具，再升级服务端，这样能在升级过程中用命令行检查状态。
# 备份全量数据 mysqldump -u root -p --all-databases --single-transaction > /backup/mysql_all.sql # 升级 MySQL 服务端及相关组件 sudo apt-get install -y mysql-server mysql-client mysql-common # 若跨大版本，使用 dist-upgrade 处理依赖变更 sudo apt-get dist-upgrade -y mysql-server
安装过程中，deb 包会调用 mysqld 的升级逻辑，对数据目录中的系统表做迁移。以 5.7 升 8.0 为例，它会将旧授权表转换为新数据字典，并提示 root 用户认证方式改为 caching_sha2_password。若原有应用使用旧驱动，需要在配置文件或 SQL 中显式改回 mysql_native_password。
升级后务必运行 mysql_upgrade 的等效检查（MySQL 8.0 之后该工具已合并进服务端启动流程），并重启服务确认错误日志无异常。可以用以下命令快速验证。
systemctl restart mysql systemctl status mysql --no-pager mysql -u root -p -e "SELECT VERSION();"
常见坑点与处理建议
第一个常见问题是配置文件不兼容。MySQL 8.0 默认开启了严格 sql_mode，而旧版可能依赖宽松模式。升级前应在 my.cnf 中评估并调整，避免业务 SQL 报错。注意这里说的 my.cnf 是配置文件名，不是 HTML 标签。
第二个坑是插件与字符集。例如旧表使用 utf8（实为三字节）而新版推荐 utf8mb4，虽然 APT 升级不会自动转换，但需要在连接层和应用层统一。若遇到认证失败，可登录后执行 ALTER USER 语句修正。整体来看，借助 APT 存储库升级虽不能免除前期调研，但能显著提升操作可控性。
| 升级方式 | 回滚难度 | 依赖处理 | 适用场景 |
|---|---|---|---|
| APT 存储库 | 低 | 自动 | 生产环境 Debian/Ubuntu |
| 二进制包手动替换 | 高 | 手动 | 特殊定制需求 |
| 系统自带源 | 低 | 自动 | 版本要求不高 |
升级后的验证清单
升级结束并不意味任务完成。建议核对用户权限表、检查慢查询日志路径、确认定时任务中的 mysql 调用路径是否变更。特别是使用第三方监控脚本时，要验证其使用的套接字文件位置是否和新版一致。
另外，如果之前启用了 binlog，需要确认 expire_logs_days 或 binlog_expire_logs_seconds 参数在新版中的命名差异。把这些细节纳入验收清单，才能保证 MySQL APT 升级真正平稳落地。
MySQLAPT_repositoryupgrade修改时间：2026-08-04 07:30:28