手动安装MySQL 5.7后mysqld.service文件不存在，systemctl启动失败的根本原因是服务未注册；需手动创建/etc/systemd/system/mysqld.service并执行systemctl daemon-reload才能生效。
手动安装的 MySQL 5.7 几乎肯定没有 mysqld.service 文件，systemctl 启动失败不是配置错，是压根没注册服务。
mysqld.service 文件根本不存在
从官网下载 tar.gz 包解压、或源码编译安装的 MySQL，mysqld.service 不会自动生成。systemd 只在两个路径找它：/etc/systemd/system/mysqld.service（优先）和 /usr/lib/systemd/system/mysqld.service（包管理器安装放这里）。运行以下命令确认：
ls /etc/systemd/system/mysqld.servicels /usr/lib/systemd/system/mysqld.service
如果都报 “No such file”，systemctl start mysqld 必然失败，且 systemctl daemon-reload 没用——没文件 reload 也没得加载。
注意：systemctl start mysqld 要求文件名严格为 mysqld.service，不是 mysql.service。查实际注册名用：systemctl list-unit-files | grep -i mysql。
ExecStart 路径或配置文件不可达
即使 service 文件存在，只要 ExecStart 指向的二进制或 --defaults-file 配置路径错误，mysqld 就会秒退，systemd 卡在 activating 状态直到超时。
- 确认
mysqld二进制存在且可执行：ls -l /usr/local/mysql/bin/mysqld - 确认
--defaults-file指向的配置文件真实存在、可读：ls -l /etc/my.cnf或你自定义的路径 - 检查该配置文件中
datadir、pid-file、log-error所指路径全部存在，且mysql用户有读写权限 - 特别注意：
log-error指向的文件若不存在，MySQL 默认不会自动创建目录或文件；sudo -u mysql touch /var/log/mysqld.log可验证写入权限
启动卡在 activating 状态但进程已在运行
现象：执行 systemctl status mysqld 显示 activating (start)，等满 TimeoutSec（默认 300 秒）后报 timeout，但 ps aux | grep mysqld 能看到进程，端口也监听着——这是 systemd 通知机制没接上。
根本原因是 mysqld 没按预期发 READY=1 信号，常见于：
-
Type=notify配置下，但 my.cnf 中innodb_buffer_pool_size过大或磁盘 I/O 慢，导致初始化耗时超 systemd 默认等待时间 - 漏配
Type=notify，或用了--skip-grant-tables等跳过初始化流程的参数 -
socket或pid-file路径权限不对，mysqld 写入失败后卡在初始化阶段
临时解法是调大 TimeoutSec=600；更稳妥的是改用 Type=simple，让 systemd 不依赖 READY 信号。
真正有用的日志在哪？
systemctl status mysqld 只告诉你“失败了”，不告诉你为什么。定位问题必须看两处：
journalctl -u mysqld.service -n 50 --no-pager —— 查 systemd 接收到的 stdout/stderr，常含 status=127（找不到命令）或 status=1（权限/配置错误）
sudo tail -n 30 $(grep 'log-error' /etc/my.cnf | awk '{print $3}') —— 直接读 MySQL 自己写的错误日志，比如 /var/log/mysqld.log，里面才有真正的初始化失败原因
80% 的启动失败，根源不在 mysqld 本身，而在路径、权限、状态三者脱节——比如 /var/lib/mysql 目录存在但属主是 root:root，或者 SELinux 标签没打对，又或者 /var/run/mysqld 这个内存目录每次重启就消失却没在 service 文件里用 RuntimeDirectory=mysqld 声明。
