臭鼠标同时装 MySQL 5.7 和 8.0，5.7 服务总消失？这套排查思路与解决配置拿走直接用
先说个现象：明明 MySQL 5.7 和 8.0 装在同一台机器上，8.0 跑得好好的，5.7 的服务却动不动就"没了"——不是启动失败，而是启动完之后过一会儿就消失，systemctl status 一看是 inactive (dead)，甚至查不到任何错误日志。这个问题在本地开发环境、测试环境反复出现，压测到一半数据库掉线，排查半天发现根本不是 SQL 的问题，而是两个 MySQL 打架。
这篇文章就是我踩完坑之后的完整复盘。里面包含了两个版本共存时的底层冲突原理、5.7 服务消失的常见原因拆解、可复现的解决步骤，以及一套我实际用了很久的 systemd 管理方案。无论你是刚接触 MySQL 多版本管理的新手，还是已经在生产环境摸爬滚打过的 DBA，这套思路应该都能直接用上。
1. 版本冲突的本质：为什么 5.7 服务会"莫名消失"
1.1 不是 MySQL 自己退出的，是环境在"挤兑"它
先说结论：5.7 服务消失，绝大多数情况下不是 mysqld 进程自己崩了，而是它所在的运行环境被另一套 MySQL 8.0 抢占或干扰，导致 5.7 根本没法正常完成初始化，或者启动后资源/配置被冲突触发，只能反复崩溃、被拉起、再崩溃，最后 systemd 彻底放弃。
我自己遇到过的典型场景是：
- 用 yum 装了 MySQL 5.7，又用官方 tar 包解压安装了 MySQL 8.0；
- 8.0 的 MySQL 服务通过 systemctl 管理，开机自启，占用 3306 端口；
- 5.7 的配置文件写在 /etc/my.cnf，datadir 指向 /var/lib/mysql；
- 启动 5.7 的时候，它会去读 /etc/my.cnf，然后尝试用 mysql 系统用户访问数据目录；
- 但 8.0 的安装过程已经把 /etc/my.cnf 覆盖了，里面写的是 8.0 的参数，比如 socket 路径、pid 文件位置、端口号；
- 5.7 启动时拿到的是 8.0 的配置，自然各种报错。
你看到的可能是"5.7 服务不存在"或者"启动后退出"，但背后真正的原因是配置串了。
这就好比你家里住进了一位新室友，他进门先改了门口的门牌号、路由器密码、冰箱分区，然后你回家发现钥匙打不开门、WiFi 连不上、牛奶被挪走了——你人没丢，是环境被改了。
1.2 systemd 与 mysqld_safe 的两套"管家"：谁是 5.7 的真正管理者
MySQL 5.7 在 Linux 上通常有两种启动方式：
- systemd 方式：通过 mysql-systemd-start 脚本和 unit 文件管理，5.7 的 unit 文件一般是 /usr/lib/systemd/system/mysqld.service；
- mysqld_safe 方式：mysqld_safe 是一个守护进程包装器，它会启动 mysqld，并在 mysqld 崩溃时自动重启它。
在同时装了 5.7 和 8.0 的环境里，经常出现一种混乱局面：你用 systemctl start mysqld 启动 5.7，但 systemd 里注册的 mysqld.service 可能已经被 8.0 的安装包覆盖了，或者两个版本各自带了不同的服务名（mysqld vs mysql），启动的时候指向了错误的可执行文件，或者 unit 文件里的 PIDFile、ExecStart 路径根本不是 5.7 的。
另一个容易踩的坑是：5.7 安装后，mysqld_safe 会把进程 fork 到后台，systemd 以为服务已经退出了，就把服务标记为 inactive，但实际上 mysqld 进程还在跑。这也会造成"服务消失"的观感——systemctl 里看不到，netstat 却发现 3307 端口还在听。
之前看到一个案例，5.7 的 systemd unit 文件里写的是：
code复制ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid
这个配置配合 systemd 是有问题的，因为 systemd 不管理 daemon 化后的进程，它认为主进程已经退出。你看到的状态就是服务处于 dead，但进程还活着。两个版本混装的时候这种问题会被放大——因为两个版本的启动脚本会互相覆盖、互相影响。
1.3 冲突的第一现场：端口、socket 文件、pid 文件
这三个东西是 MySQL 多版本共存的"必争之地"，
也是 5.7 服务起不来的第一现场。
默认情况下：
- MySQL 默认端口是 3306；
- socket 文件默认路径是 /var/lib/mysql/mysql.sock 或者 /tmp/mysql.sock；
- pid 文件默认路径是 /var/run/mysqld/mysqld.pid；
- 默认 datadir 是 /var/lib/mysql。
如果你在 8.0 已经占用 3306 的情况下，再启动 5.7 而且没改端口，5.7 会抛出类似：
code复制ERROR 2002 (HY000): Can't connect to local MySQL server through socket...
[ERROR] Aborting
如果恰好 5.7 的配置里端口不一致，或者干脆没读到自己该读的配置，那五次启动五次失败，systemd 触发 StartLimitBurst，直接把服务列入 failed 状态。你会看到：
code复制Job for mysqld.service failed because a fatal signal was delivered...
还有一种情况，就是 pid 文件冲突。5.7 和 8.0 的 pid 文件名如果都叫 mysqld.pid，而且两个进程都尝试写入同一个路径，后启动的那个可能因为无法创建 pid 文件而启动失败。这就像两个人都抢着写同一张便签纸，先到的把名字写上去，后来的发现自己名字写不上去，干脆罢工。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心细节：5.7 服务消失背后的"隐形手"
2.1 配置文件覆盖链：my.cnf 到底被谁抢走了
MySQL 的配置文件读取顺序是：
code复制/etc/my.cnf
/etc/mysql/my.cnf
/usr/etc/my.cnf
~/.my.cnf
默认情况下，5.7 和 8.0 都会去读 /etc/my.cnf。如果你先装了 5.7，再装 8.0，8.0 的 RPM 或二进制包很可能会覆盖 /etc/my.cnf。因为 8.0 的默认配置和 5.7 差距较大，覆盖后 5.7 读取到的参数自然就会出问题。
所以我一直强调：
多版本共存时必须为每个版本单独指定配置文件，不能完全依赖默认路径。
比如给 5.7 单独配置 /etc/my57.cnf，启动时用：
code复制mysqld --defaults-file=/etc/my57.cnf
这样 8.0 怎么改 /etc/my.cnf 都不会影响 5.7。systemd 的 unit 文件里也要用 --defaults-file 指明确切路径。
如果你查看 5.7 的日志，发现大量的参数是 8.0 才有的（比如 validate_password 插件策略、default_authentication_plugin），那基本就是配置文件被串了。5.7