最常见原因是mysqld_safe文件存在但其所在目录（如/usr/local/mysql/bin）未加入PATH环境变量；其次为MySQL 5.7.20+官方包在systemd系统中默认不安装该工具，或编译安装时basedir配置错误、权限不足、依赖缺失导致启动失败。
mysqld_safe 命令根本不在 PATH 中
最常见的情况是：mysqld_safe 文件确实存在，但它的所在目录（比如 /usr/local/mysql/bin 或 /opt/mysql/bin）没被加进 PATH 环境变量。系统执行命令时只在 PATH 列表里找，找不到就报 -bash: mysqld_safe: command not found。
验证方法：echo $PATH 看输出里有没有 MySQL 的 bin 目录；which mysqld_safe 返回空也说明不在 PATH 里。
- 临时修复：运行
export PATH=$PATH:/usr/local/mysql/bin（路径按你实际安装位置替换） - 永久修复：把上面那行加到
~/.bashrc或/etc/profile，再source ~/.bashrc - 注意：如果用
sudo执行，sudo默认不继承用户 PATH，得用sudo -E或直接写绝对路径
MySQL 安装包压根没带 mysqld_safe
从 MySQL 5.7.20 起，官方 RPM/DEB 包在 systemd 系统上默认不安装 mysqld_safe —— 因为 systemd 已接管启动、重启、日志等职责，mysqld_safe 变成冗余组件。OpenEuler、CentOS 8+、Ubuntu 20.04+ 等都属于这类系统。
确认方式：systemctl status mysqld 或 systemctl status mysql 能看到服务状态，且 find / -name mysqld_safe 2>/dev/null 返回空，基本可判定没装。
- 别硬找
mysqld_safe，改用systemctl start mysqld --skip-grant-tables不行（systemd 不支持该参数），应改配/etc/my.cnf加[mysqld]段：skip-grant-tables+skip-networking，再systemctl restart mysqld - MySQL 8.0+ 更进一步：官方文档明确标注
mysqld_safe已废弃，所有启动逻辑应通过mysqld直接或 systemd 管理
编译安装时 basedir 配置错或文件权限不对
源码编译安装（如 ./configure --prefix=/usr/local/mysql）后，mysqld_safe 默认生成在 ${prefix}/bin/mysqld_safe。但它启动时会读配置文件里的 basedir，如果 my.cnf 中写的是 basedir=/usr，它就会去 /usr/bin/mysqld_safe 找，自然失败。
同时，若 mysqld_safe 文件权限不是 755，或属主不是运行用户（如 mysql），也会静默失败或报“Permission denied”。
- 查真实路径：
find /usr/local -name mysqld_safe 2>/dev/null - 检查配置：
grep basedir /etc/my.cnf /usr/local/mysql/etc/my.cnf 2>/dev/null，确保值和实际安装路径一致 - 修权限：
chmod 755 /usr/local/mysql/bin/mysqld_safe，再chown mysql:mysql /usr/local/mysql
用绝对路径调用仍失败的几个关键点
即使写了完整路径，比如 /usr/local/mysql/bin/mysqld_safe --skip-grant-tables &，也可能卡住或退出，原因常被忽略：
-
mysqld_safe启动前会尝试调用mysqld，而它依赖basedir下的libexec/mysqld或bin/mysqld—— 如果这个二进制缺失或路径错，会报 “The server quit without updating PID file” - 它默认读
/etc/my.cnf，但如果该文件里[mysqld]段指定了错误的datadir，会导致初始化失败，日志通常在$datadir/hostname.err - 某些 OpenEuler/CentOS 镜像精简过，缺
libaio或numactl，mysqld进程起不来，mysqld_safe就自动退出，查journalctl -u mysqld才能看到真正错误
真正麻烦的不是找不到命令，而是找到之后它不肯好好干活——mysqld_safe 是个“包装器”，它不处理核心逻辑，只负责兜底和转发。一旦底层 mysqld 启动失败，它往往只默默退出，连错误都不打全。动手前先确认 mysqld 本身能不能跑起来，比死磕 mysqld_safe 有效得多。
