mysql 8.0 systemctl start mysqld报“unit not found”或卡在activating，主因是mysqld.service文件缺失或路径错误；需确认其是否存在于/etc/systemd/system/或/usr/lib/systemd/system/，且execstart路径、--defaults-file配置真实有效，并检查journalctl和error log定位阻塞点。
MySQL 8.0 安装成功但 systemctl start mysqld 报 “unit not found” 或卡在 activating (start)，大概率不是 MySQL 本身坏了，而是 systemd 没找到服务定义，或者找到了但启动逻辑被阻塞——核心问题在 Unit 文件是否真实存在、路径是否正确、内容是否匹配你的部署结构。
确认 mysqld.service 文件是否存在且路径正确
systemd 只认两个标准位置的 Unit 文件：/etc/systemd/system/mysqld.service（优先级高，用于自定义）和 /usr/lib/systemd/system/mysqld.service（包管理器安装时放这里）。手动编译或解压安装的 MySQL 通常不会自动生成这个文件。
- 运行
ls /etc/systemd/system/mysqld.service和ls /usr/lib/systemd/system/mysqld.service，任一存在才算“有文件” - 如果都不存在，
systemctl start mysqld必然报Unit mysqld.service not found；此时不能直接systemctl daemon-reload，那没用 - 注意：有些教程写的是
mysql.service而非mysqld.service，名字必须和你执行的命令一致。查systemctl list-unit-files | grep -i mysql看实际注册名
Unit 文件里 ExecStart 路径和配置文件必须真实可访问
即使文件存在，如果 ExecStart 指向了不存在的二进制或错误的 --defaults-file，mysqld 进程会立即退出或挂起，systemd 就一直等它发 READY=1 信号，直到 TimeoutSec 超时（常见报错 Job for mysqld.service failed because a timeout was exceeded）。
- 检查
ExecStart中的路径，比如/usr/local/mysql8.4/bin/mysqld，确认该文件存在且有执行权限：ls -l /usr/local/mysql8.4/bin/mysqld - 检查
--defaults-file参数指向的配置文件，比如/data/mysql/mysql3306/etc/my.cnf，确认路径存在、文件可读、且里面datadir、pid-file等路径也都真实有效 - 特别注意：如果配置文件里写了
log-error=/var/log/mysqld.log，但/var/log下没有mysqld.log文件且 MySQL 用户无权创建，mysqld 会静默失败，systemd 看不到错误日志，只看到超时
启动卡住时，别只看 systemctl status，要盯 journalctl 和错误日志
systemctl status mysqld 只显示状态摘要，真正卡在哪，得看实时输出和 MySQL 自己的日志。
- 立刻执行
journalctl -u mysqld -f（加-f实时跟踪），启动时能看到 mysqld 启动瞬间的 stdout/stderr，比如 “Can’t open the mysql.plugin table” 或 “File ‘./binlog.index’ not found (OS errno 13)” - 如果 journal 里没线索，就去查 MySQL 配置里
log-error指定的文件，比如tail -n 20 /var/log/mysqld.log，最后一行往往是致命错误 - 常见干扰项：SELinux 启用状态下，
mysqld无法访问datadir或log-error目录，journalctl里会出现avc: denied，但systemctl status完全不提这回事
为什么 service mysqld start 能跑，systemctl 却不行
因为 service 是兼容层，它调的是 /etc/init.d/mysqld 脚本（通常是旧式 SysV init 脚本），而 systemctl 强制走 systemd 的 Unit 文件机制。两者完全不共享配置。
- 如果你用
support-files/mysql.server拷过去并service mysqld start成功了，不代表 systemd 配置就对了——这只是绕过了 systemd - 不要混用：要么彻底迁移到 systemd（删掉
/etc/init.d/mysqld，只维护mysqld.service），要么就坚持用service命令，但会丢掉Restart=on-failure、资源限制等 systemd 特性 - 注意
mysql.server脚本内部硬编码的basedir和datadir，可能和你my.cnf里的不一致，导致行为差异
最易被忽略的一点：systemd 的 Type=notify 要求 mysqld 主动发 readiness 信号，而某些旧版或定制编译的 mysqld 不支持。如果不确定，先改成 Type=simple 测试——这不是修复，是快速验证是否卡在通知机制上。
