mysql连接失败主因是socket文件路径错误、权限不足或服务未运行，需按“服务状态→socket生成→路径匹配→权限检查”顺序排查，-h 127.0.0.1可绕过socket快速验证服务可用性。
mysql.sock 文件找不到或路径不对
MySQL 客户端默认通过 Unix socket 文件（mysql.sock）连接本地服务，而不是走 TCP 的 127.0.0.1:3306。如果报 Can't connect to local MySQL server，第一反应不是服务没启，而是客户端根本没找到 socket 文件。
常见原因：MySQL 服务实际把 mysql.sock 放在了非标准路径（比如 /var/lib/mysql/mysql.sock、/tmp/mysql.sock、/usr/local/mysql/tmp/mysql.sock），但客户端仍在默认路径（如 /tmp/mysql.sock）找。
- 查服务端实际路径：
mysql -u root -p -e "SHOW VARIABLES LIKE 'socket';"（需服务已运行） - 若服务未启动，直接看配置：
grep socket /etc/my.cnf /usr/my.cnf /usr/local/etc/my.cnf 2>/dev/null - 启动时指定 socket：
mysqld --socket=/var/run/mysqld/mysqld.sock --user=mysql & - 客户端显式指定：
mysql --socket=/var/lib/mysql/mysql.sock -u root -p
mysql.sock 权限不足导致拒绝访问
即使 mysql.sock 文件存在且路径正确，如果权限设置太严格（比如属主不是运行 MySQL 的用户，或没有其他用户执行权限），客户端会静默失败，错误信息仍显示为“无法连接服务器”。
Unix socket 是一种特殊文件，需要对 socket 文件本身有读写权限，且其**父目录必须有执行（x）权限**——否则进程无法进入该目录完成连接 handshake。
- 检查 socket 文件权限：
ls -l /var/lib/mysql/mysql.sock，确认属主是mysql（或你启动 mysqld 的用户） - 检查父目录权限：
ls -ld /var/lib/mysql/，确保包含x（如drwxr-x---可，drw-r-----不可） - 临时修复：
sudo chmod 755 /var/lib/mysql/ && sudo chown mysql:mysql /var/lib/mysql/mysql.sock - 不要用
chmod 777，这会破坏 MySQL 安全模型，可能触发 SELinux 或 AppArmor 拒绝
MySQL 服务根本没运行，但错误提示误导人
这个错误最常被误判为网络或权限问题，其实只是 mysqld 进程根本不存在。Linux 下 socket 文件不会自动清理，旧的 mysql.sock 可能残留，但没进程监听，连上也无响应。
- 确认进程是否存活：
ps aux | grep mysqld | grep -v grep，或systemctl status mysql（Ubuntu/Debian）/systemctl status mysqld（CentOS/RHEL） - 查看错误日志定位启动失败原因：
tail -20 /var/log/mysql/error.log或journalctl -u mysqld -n 30 - 常见启动失败点：磁盘满、
my.cnf语法错误、datadir权限错、InnoDB 日志损坏 - 别依赖
netstat -ln | grep mysql—— socket 连接不体现在 TCP 端口列表里
客户端绕过 socket、强制走 TCP 连接来排查
如果你只想快速验证 MySQL 服务是否真在工作，又不想纠缠 socket 路径和权限，最干净的办法是让客户端放弃 Unix socket，改用 TCP 回环连接。这能跳过所有 socket 相关路径/权限校验，直击服务可用性本身。
- 加
-h 127.0.0.1强制走 TCP：mysql -h 127.0.0.1 -u root -p - 注意：
-h localhost在 MySQL 客户端中默认仍走 socket，必须是 IP 字面量才走 TCP - 如果
-h 127.0.0.1成功，而-h localhost失败，100% 是 socket 配置或权限问题 - 此方法不能解决生产环境连接逻辑，仅用于快速隔离问题域
