从MySQL 5.1升级到8.0？先看这篇CentOS彻底卸载旧版的避坑教程

从MySQL 5.1升级到8.0？先看这篇CentOS彻底卸载旧版的避坑教程

最近在帮几个朋友的公司做数据库架构升级，发现一个挺普遍的现象：很多运维团队对MySQL 8.0的新特性垂涎已久，比如窗口函数、JSON增强、性能提升，但真到了要动手升级的时候，却卡在了第一步——怎么把老版本干净利落地从系统里请出去。特别是那些还在跑着MySQL 5.1甚至更老版本的CentOS服务器，系统里各种依赖盘根错节，直接用yum remove或者rpm -e，轻则报一堆依赖错误，重则直接把邮件服务postfix这类看似无关的组件给连带卸载了，导致业务中断。我自己就吃过这个亏，有一次在测试环境没清理干净残留的库文件，结果新装的MySQL 8.0启动直接报错，排查了大半天才发现是旧版的my.cnf配置和libmysqlclient.so在捣乱。

所以，这篇文章不是一篇简单的命令罗列，而是想和你分享一套经过实战检验的、面向生产环境的CentOS系统MySQL旧版彻底卸载流程。我们会深入探讨不同安装方式（RPM vs YUM）带来的卸载差异，手把手教你定位并清理那些隐藏的残留文件和库，更重要的是，会重点讲解如何避免误伤像postfix这样的关键依赖服务。最后，我们还会把视角拉远一点，聊聊在动刀卸载之前，你必须做好的数据备份和升级路径规划。毕竟，对于数据库这种核心组件，“干净”是升级成功的基石，而“安全”则是整个操作不可逾越的底线。

1. 升级前奏：理解卸载的本质与风险

在动手敲下任何删除命令之前，我们得先搞清楚在Linux系统里，一个软件包到底意味着什么。很多人以为卸载就是yum remove mysql，其实远不止如此。在CentOS/RHEL体系下，MySQL的安装痕迹遍布好几个地方，粗略可以分为以下几个层面：

• 包管理层面：这是最上层，由rpm或yum管理。记录了包的安装信息、文件清单和依赖关系。
• 服务与进程层面：运行中的mysqld守护进程、系统的systemd或init.d服务单元。
• 配置文件层面：/etc/my.cnf以及可能存在的/etc/my.cnf.d/目录下的配置。
• 数据文件层面：默认在/var/lib/mysql/下的所有数据库文件，这是你的核心资产。
• 运行时库与头文件层面：/usr/lib64/mysql/下的共享库（如libmysqlclient.so）和/usr/include/mysql/下的开发头文件。
• 日志与临时文件层面：/var/log/mysqld.log等日志文件，以及可能的socket文件、pid文件。

一个不彻底的卸载，往往只清理了第一层（包管理信息），而后面几层的残留物，会成为新版本安装和运行的“幽灵”，引发各种诡异问题。比如，残留的旧版libmysqlclient.so可能导致新安装的客户端工具连接失败；老旧的/etc/my.cnf配置项可能与MySQL 8.0不兼容，导致服务无法启动。

注意：本文讨论的“彻底卸载”，目标是为全新安装MySQL 8.0扫清障碍。如果你的目的是原地升级（In-Place Upgrade），那么绝对不能直接卸载旧版，而应遵循官方的升级手册，那完全是另一套流程。

1.1 识别你的MySQL安装方式

卸载策略因安装方式而异。首先，我们需要侦探一下当前MySQL是怎么来的。

方法一：使用rpm查询

rpm -qa | grep -i mysql

这条命令会列出所有名字中包含“mysql”的RPM包。典型的输出可能包括：

mysql-community-server-5.1.73-8.el6.x86_64
mysql-community-client-5.1.73-8.el6.x86_64
mysql-community-libs-5.1.73-8.el6.x86_64
mysql-community-common-5.1.73-8.el6.x86_64

如果看到这样的包名，说明是通过MySQL官方仓库或RPM包直接安装的。

方法二：检查YUM历史