【解决】mysql卸载之后安装不同的版本导致mysqld无法启动

一. 背景

说起来也是个巧合，在我安装mysql5.7版本的时候，看走眼了，安装成mysql8.0版本的了。于是乎，我当时觉得8.0，嗯，比5.7数字要大，那么一定更先进！实际上，却大有不同。

其实看走眼我认为也是一件再正常不过的事（试图为自己辩解），如图：

好了，回到正题。安装了8.0之后，实际上操作数据库是没什么区别的。但是在配置的现象上确有很大差别。比如，我配置了my.cnf的免密登陆之后，查看对应服务器的进程却查看不到，这是由于8.0相比5.7版本，安全防护做的更好。

如果你用的5.7版本，那么一旦你的数据库设置了免密登陆的配置，极有可能出现如下的结果：

（借用wechat通讯录某位大佬亲身经历的事情…)

那么，我配置了8.0的为什么还要换成5.7的呢？作为小白一个，肯定是为了学习方便，即便出现上述情况，我也没什么重要的数据可丢失的。于是乎，我按照正常的卸载不要的环境的处理方法，把之前的mysql处理干净（自认为卸载干净了），在启动时，出现了我预料之外的状况…

MySQL环境配置_

二. 出现的问题

当我重新安装好mysql5.7版本，试图启动（此时脑子里冒出来了：原神，启动！的声音），竟出现了这样的情况：

哦，启动失败…。***

---

此时，肯定是要用GPT的。

一条一条的看：

1. 首先是配置问题，我刚刚安装的mysql能有什么问题？？？过，肯定不是这个原因。
2. 权限？怎么可能，过。
3. 端口冲突。emm，想了一会儿，确实可能，结果我查看netstat -tuln | grep 3306，(mysqld默认是3306)，也不是这个问题。过。
4. 资源限制？这就更离谱了，不可能，绝对不可能。
5. 四个都没了，让我看日志。我日，我怎么看得懂…。过。

好了，结论是，ChatGPT的回答让我很不满意。

于是乎，问了真正的大佬：

三. 问题的原因

出现了这种情况，是因为在卸载mysql的时候，虽然配置什么的都随着mysql本身一起卸载干净了，但是里面的/var/lib路径中的mysql目录仍然存在，这个目录是已经卸载掉的8.0的数据的目录。这时如果像我一样安装了mysql5.7版本的数据库，那么在启动时它也会生成一个mysql的目录，此时mysql目录名已经有了，而且因版本不同，里面的数据格式自然也不同，不能覆盖，也不能替换。所以就出现了最开始启动失败的情况。

四. 解决方式

实际上，只需要将之前的mysql目录名改成别的名字，或者删除，让新生成的mysql目录与其不产生冲突，就可以解决了。