mysqld 未运行是 socket 连接失败的首要原因，需先用 systemctl status 和 ps 命令确认进程状态；若未启动，再排查 my.cnf 错误、权限、磁盘、端口、user 配置等问题。
mysqld 进程根本没跑起来
报 Can't connect to local MySQL server through socket，第一反应不该是找文件，而是确认服务是否真在运行。很多情况下，mysql.sock 压根没机会生成——因为 mysqld 启动就失败了。
- 执行
systemctl status mysql（或mysqld，取决于发行版），看状态是不是active (running) - 若显示
inactive (dead)或failed，直接跳过查路径环节，先解决启动失败 - 常见硬卡点：
my.cnf语法错误、datadir权限不对（比如属主不是mysql）、磁盘满、端口 3306 被占、user=root配置（5.7+ 默认禁止 root 启动） - 补一手验证：
ps aux | grep mysqld，只看到grep自己那行，说明主进程确实没起来
socket 路径在服务端和客户端不一致
mysql.sock 是 mysqld 启动时动态创建的，它的位置由服务端配置决定；而客户端默认只认一个固定路径（通常是 /tmp/mysql.sock）。两者对不上，就会“找不到”。
- 查服务端实际用的路径：
mysqld --help --verbose 2>/dev/null | grep "socket"，找带Default options的那行输出 - 或登录成功后执行：
SELECT @@socket;（前提是能连上，比如用mysql -h 127.0.0.1 -u root -p走 TCP） - 查配置文件：
grep -r "socket =" /etc/mysql/ /etc/my.cnf 2>/dev/null，重点看[mysqld]段 - 客户端也要同步改：在
~/.my.cnf或/etc/my.cnf的[client]段写入socket = /var/run/mysqld/mysqld.sock（值必须和服务端完全一致） - 临时救急：
mysql -u root --socket=/var/run/mysqld/mysqld.sock
目录权限不足导致 sock 文件无法创建
服务起来了、路径也配对了，但 mysql.sock 就是不出现？大概率是 mysqld 用户（通常是 mysql）没权限在目标目录里写文件。
- 运行
ls -ld /var/run/mysqld（把路径替换成你查到的实际 socket 父目录），确认属主是mysql:mysql - 如果不是，执行：
sudo chown mysql:mysql /var/run/mysqld - 目录权限至少要是
755；若为700且属主非mysql，mysqld会静默失败，日志里可能只有Can't start server : Bind on unix socket: Permission denied -
/tmp下的mysql.sock极易被systemd-tmpfiles清理掉——这不是 bug，是设计行为，生产环境别硬塞这儿
配置冲突或残留导致 mysqld_safe 清除 sock
某些场景下，mysqld_safe 会主动删掉旧的 mysql.sock 和 hostname.pid，尤其当它发现授权表损坏、用户权限错乱或配置不一致时。
- 先杀掉所有残留进程：
ps aux | grep mysqld→kill -9掉所有相关 PID - 检查
/etc/my.cnf中[mysqld]段的user是否设为mysql（不要设root） - 若用二进制安装，且之前手动跑过
mysqld --user=root &，可能导致数据目录权限混乱，需重建授权表：mysql_install_db --user=mysql --basedir=/usr/local/mysql --datadir=/usr/local/mysql/data - 再启动：
mysqld_safe --user=mysql &，观察error.log是否有Starting mysqld daemon with databases from成功提示
mysql.sock 不是静态文件，它依赖服务启动流程的每一步都走通——进程、配置、权限、路径，缺一不可。任何一环出问题，它都不会凭空出现。**
