systemctl enable mysqld报“no such file or directory”是因为mysqld.service文件缺失；常见原因包括手动解压安装未自带unit文件、yum安装后文件被误删、非标准安装路径，或服务名实际为mysql而非mysqld。
systemctl enable mysqld 通常就能搞定，但前提是 MySQL 安装方式匹配 systemd 管理逻辑。直接硬套命令却失败，大概率是安装路径、用户权限或配置项对不上。
为什么 systemctl enable mysqld 报错 “No such file or directory”？
这不是命令错了，而是系统根本没找到 mysqld.service 文件。常见原因有：
• 用二进制包手动解压安装（比如 mysql-8.0.41-linux-glibc2.28-x86_64），官方没提供 systemd unit 文件
• YUM 安装后 /usr/lib/systemd/system/mysqld.service 被误删或路径被改过
• 安装时用了非标准前缀（如 --prefix=/opt/mysql），导致 systemd 找不到服务定义
• 某些发行版（如旧版 CentOS 7）默认只带 mysql.service，而你执行的是 mysqld
验证方法：ls /usr/lib/systemd/system/mysqld.service 或 ls /usr/lib/systemd/system/mysql*。没有就别硬启，得自己写。
手写 mysqld.service 必须填对的三个字段
放在 /etc/systemd/system/mysqld.service，内容不能只抄模板，以下三项必须严格匹配你的实际环境：
-
User=和Group=必须设为mysql（不是root，否则启动报 Permission denied） -
ExecStart=必须用绝对路径，且带上--daemonize参数，例如：/usr/local/mysql/bin/mysqld --daemonize --pid-file=/usr/local/mysql/data/mysqld.pid -
PIDFile=必须和my.cnf中[mysqld]下的pid-file值完全一致；如果my.cnf没配，systemd 就找不到进程，超时后判定启动失败
写完务必运行：sudo systemctl daemon-reload，否则 enable 会提示 service not found。
YUM 安装后仍无法自启的典型陷阱
YUM 安装（如 mysql-community-server）本应自带服务文件，但以下情况会导致 systemctl enable mysqld 成功却开机不启动：
-
my.cnf中datadir指向的目录属主不是mysql:mysql，systemd 启动时因权限不足静默退出 - SELinux 开着且策略未放行，
systemctl status mysqld里能看到avc: denied日志 - 防火墙开着但没放行 3306，虽然不影响服务启动，但新手常误判为“没起来”，其实
netstat -tlnp | grep :3306能确认端口监听状态 -
systemctl is-enabled mysqld返回disabled，说明上次enable没生效——可能因为daemon-reload漏了，或服务名实际是mysql而非mysqld
rc.local 方式仅限应急，别当主力
/etc/rc.local 是 systemd 时代最后的兜底手段，但有硬性前提：
- 确保
/etc/rc.local存在且有执行权限：sudo chmod +x /etc/rc.local - 脚本里必须用绝对路径启动，例如：
/usr/local/mysql/bin/mysqld_safe --user=mysql & - 开头加
#!/bin/bash，末尾加exit 0，否则 systemd 会卡住 - 它不支持依赖管理（比如等网络就绪再启动），也不受
systemctl控制，查状态、重启都得手动操作
真正要稳定跑生产环境，绕不开 systemd 的正确配置。rc.local 只适合快速验证或受限容器里临时顶一下。
真正卡住的点往往不在“怎么写 service 文件”，而在 User/Group 权限、PIDFile 路径一致性、以及daemon-reload 是否漏执行——这三个地方错一个，服务就起不来，还很难从日志一眼看出根源。
