MySQL客户端报“Check that mysqld is running”仅为默认错误提示，并非服务真实状态；实际需查进程（ps aux | grep mysqld）、端口监听（ss -tlnp | grep :3306）及socket路径一致性，优先分析错误日志（如/var/log/mysql/error.log）定位根本原因。
这个提示根本不是MySQL在报错，而是客户端在“瞎猜”——它只说明 mysql 命令连不上服务，并不表示服务一定没运行，也不代表服务真的启动失败了。
为什么 mysql 命令会报 “Check that mysqld is running”
这是 MySQL 客户端（mysql）在连接失败时的默认 fallback 提示。它只做了两件事：
① 尝试通过 socket 文件（如 /tmp/mysql.sock）连接本地服务；
② 连不上就直接甩出这句万能话术，不查日志、不验进程、不看配置。
常见触发场景包括：
-
mysqld其实已启动，但 socket 路径和客户端预期的不一致（比如my.cnf里设的是/var/lib/mysql/mysql.sock，而客户端默认找/tmp/mysql.sock） -
mysqld正在启动中，但还没完成初始化（尤其是 InnoDB 恢复慢时，mysql命令超时退出） - 服务以非标准用户运行（如
root启动但 socket 文件属主是mysql），导致客户端无权访问 socket 文件
怎么确认 mysqld 到底有没有真正在跑
别信提示，直接查进程和监听状态：
- 看进程是否存在：
ps aux | grep mysqld | grep -v grep—— 如果输出里有mysqld且不是mysqld_safe包装器，说明服务进程活着 - 看端口是否监听：
ss -tlnp | grep :3306或netstat -tlnp | grep :3306—— 若看到LISTEN且 PID 对应 mysqld，说明 TCP 层已就绪 - 看 socket 文件是否存在且可访问：
ls -l $(mysql --help 2>/dev/null | grep "Default options" | awk '{print $NF}')/my.cnf 2>/dev/null | grep socket，再手动检查那个路径下的文件是否真实存在、权限是否允许当前用户读写
my.cnf 中 socket 配置不一致的典型坑
很多故障其实就卡在 [client] 和 [mysqld] 两节的 socket 值不统一。例如：
[mysqld] socket = /var/lib/mysql/mysql.sock [client] socket = /tmp/mysql.sock
结果就是：服务把 socket 创建在 /var/lib/mysql/，而客户端坚持去 /tmp/ 找 —— 自然报那句“Check that mysqld is running”。解决方法只有两个：
- 统一两处
socket路径（推荐） - 连接时显式指定：
mysql -u root -p --socket=/var/lib/mysql/mysql.sock
真正该优先看的日志位置
客户端提示毫无价值，关键线索全在服务端日志里。先定位日志路径：
- RHEL/CentOS：
/var/log/mysqld.log - Debian/Ubuntu：
/var/log/mysql/error.log - 源码安装或自定义
datadir：$datadir/$(hostname).err（如/usr/local/mysql/data/myhost.err）
然后立刻执行：tail -n 30 /path/to/error.log。真正致命的问题（比如 InnoDB: Unable to lock ./ibdata1、Can't start server: Bind on TCP/IP port: Address already in use、unknown variable 'innodb_force_recovery'）全在这里，而不是在客户端那句废话里。
最常被忽略的一点：即使 systemctl start mysql 返回 success，也可能只是“提交了启动请求”，服务其实在后台静默崩溃了——所以每次怀疑启动失败，第一反应不该是重试 mysql -u root，而是直奔 error log 看最后一行。
