博客提示连不上数据库，再查服务却得到 mysqld.service could not be found，只能说明这个服务名没有找到对应unit，不能据此断言MySQL未安装或数据已丢失。

2020年的转折，是从日志找到了程序

当时几天没登录博客，后台突然报数据库连接失败。我先查mysqld状态，但服务名找不到；又在常见安装目录里找程序，也没找到。

后来先发现数据与日志目录，再从日志里找到这台机器使用的服务端路径：

/usr/libexec/mysqld

这是那次安装的历史路径，不是所有Linux MySQL的标准位置。客户端 mysql、服务端 mysqld、服务注册名、配置文件和datadir，应分别识别。

先识别管理方式和已有实例

在使用systemd的环境中，可先观察已安装unit和相关进程：

systemctl list-unit-files --type=service
ps -eo pid,user,args
command -v mysql
command -v mysqld

从结果中确认实际服务名、程序参数和安装包；输出可能含敏感参数，分享前脱敏。某些发行包叫mysql.service，有些叫mysqld.service，也可能使用其他管理方式。MySQL systemd管理说明

找不到PATH里的mysqld，不表示文件一定不存在；反过来，磁盘上有二进制，也不说明它正是当前实例使用的版本。

不凭二进制路径盲目启动

旧记录最后以mysql用户手工启动程序，但没有留下明确的配置文件、datadir、socket和进程托管方式。维护时应先确认没有另一个实例占用同一数据目录，检查运行账号及文件权限，再按原管理方式恢复服务。

不要初始化现有数据目录、随意换二进制版本或直接用root启动来试错。找到日志后，继续看停止原因、磁盘容量、配置与权限，不把“启动命令执行了”当作故障已解释。

数据库与博客都要分别验证

数据库侧看启动日志、进程和预期连接端点；应用侧核对连接方式、凭据与实际查询。若本机socket与TCP行为不同，可参考localhost与IP连接层次。

这次历史记录不足以证明服务注册为何消失；它保留下来的排障价值，是沿实际日志寻找实例身份，而不是反复猜安装路径。