直接结论：不是 mysql 没装好，而是 systemd 根本没拿到它的“上岗证”——mysql.service 文件；需先确认安装方式（包管理器安装应自动生成 unit 文件，tar 包解压则默认不生成），再检查真实服务名（如 mysqld 或 mysql）、unit 文件是否存在及路径是否正确，并确保 execstart、--defaults-file、user/group 配置真实有效，最后执行 systemctl daemon-reload。
systemctl status mysql 报 Unit not found 怎么办
直接结论：不是 MySQL 没装好，而是 systemd 根本没拿到它的“上岗证”——mysql.service 文件。这个报错只说明服务单元缺失，和 MySQL 二进制是否可用、数据目录是否存在无关。
先确认你用的是哪种安装方式
不同安装路径，处理逻辑完全不同：
- 用
yum install mysql-server或apt install mysql-server安装的，mysql.service应该自动落地到/usr/lib/systemd/system/；如果没出现，大概率是包安装中途失败或被跳过（比如只装了 client 而非 server） - 从官网下载 tar.xz 包解压部署的（如
mysql-8.0.xx-linux-glibc2.xx-x86_64），默认**完全不生成**任何 systemd 文件，这是设计使然，不是 bug - Docker 启动的 MySQL 容器，宿主机上本来就不存在
mysql.service，查这个纯属方向错误
手动创建 mysql.service 文件要注意什么
如果你确定要走手动注册这条路，别照抄网上模板就完事。以下几点踩坑最多：
-
ExecStart必须指向真实可执行文件，常见错误是写成/usr/bin/mysqld，但实际路径可能是/opt/mysql/bin/mysqld或/usr/local/mysql/bin/mysqld，用which mysqld或find / -name mysqld 2>/dev/null确认 -
--defaults-file参数必须显式指定配置文件路径，否则mysqld启动时可能因找不到my.cnf直接退出，systemd 看到的就是 “failed” - 不要漏掉
User和Group设置，MySQL 进程若以 root 身份启动，后续初始化或权限校验会失败；通常应设为mysql - 写完后必须运行
systemctl daemon-reload，否则systemctl start mysql仍会报 not found
service mysqld start 为什么有时能用
某些旧版发行版（如 CentOS 7 早期、RHEL 6）或部分 MySQL 包，注册的服务名是 mysqld 而非 mysql。这不是拼写错误，而是历史命名差异：
- 运行
ls /lib/systemd/system/mysqld*或systemctl list-unit-files | grep mysqld查看真实服务名 - Ubuntu 22.04+ 默认用
mysql，CentOS 7 默认用mysqld，MariaDB 则常用mariadb - 别强行改名，直接用系统已有的服务名更稳妥；
systemctl start mysqld成功，就说明你该用这个名
真正容易被忽略的点在于：服务名不统一 + 安装方式混杂，会导致你以为“装了却没服务”，其实是找错了名字或路径。动手前先 find /usr -name "*.service" | grep -i sql 看一眼，比盲目重装快得多。
