90%的“Can't connect to local MySQL server through socket”错误源于客户端与服务器socket路径不一致或服务未启动导致socket文件未生成；需先确认MySQL服务状态，再查实际socket路径并统一客户端配置。
直接说结论：90% 的 Can't connect to local MySQL server through socket 错误，不是数据库坏了，而是客户端和服务器“约错了见面地点”——socket 路径不一致，或文件根本没生成出来。
确认 MySQL 服务是否真在运行
别跳步。很多情况下，错误提示只是表象，实际是服务压根没起来。
- 运行
sudo systemctl status mysql（Debian/Ubuntu）或sudo systemctl status mysqld（RHEL/CentOS），看状态是不是active (running) - 如果显示
inactive (dead)或failed，说明服务启动失败，mysql.sock根本不会被创建 - 此时要查日志：
sudo tail -n 20 /var/log/mysql/error.log或sudo journalctl -u mysql --since "1 hour ago"，重点找Can't create/write to file、Permission denied、Directory not found这类线索 - 常见卡点：/var/run/mysqld 目录不存在（尤其重装或手动部署后），需手动建目录并赋权：
sudo mkdir -p /var/run/mysqld && sudo chown mysql:mysql /var/run/mysqld
找到服务器实际使用的 socket 路径
不能猜，也不能信默认值。MySQL 启动时按配置写路径，你得去问它本人。
- 如果服务能连上（比如用
mysql -h 127.0.0.1 -P 3306 -u root -pTCP 方式），就直接执行：mysql -u root -p -e "SHOW VARIABLES LIKE 'socket';" - 如果连不上，就查配置文件：
grep -r "socket=" /etc/mysql/ /etc/my.cnf 2>/dev/null，注意看[mysqld]段落下的socket行 - 常见真实路径有：
/var/run/mysqld/mysqld.sock、/var/lib/mysql/mysql.sock、/tmp/mysql.sock、/usr/local/mysql/tmp/mysql.sock（取决于安装方式） - 用
find /var /tmp /usr -name "mysql.sock" 2>/dev/null快速扫一遍，但注意：找不到 ≠ 不存在，可能服务根本没成功写入
让客户端和服务器用同一个 socket 路径
客户端默认只认 /tmp/mysql.sock，而服务器很可能写了别的位置——这是最常踩的坑。
- 临时绕过：连接时显式指定路径，例如：
mysql -u root -p --socket=/var/run/mysqld/mysqld.sock - 永久修复（推荐）：在
[client]段落里配好路径，避免每个命令都加--socket。sudo nano /etc/mysql/my.cnf，加入：[client] socket = /var/run/mysqld/mysqld.sock
注意：这个路径必须和[mysqld]段里的socket完全一致 - 别用软链治标不治本：虽然
sudo ln -sf /var/run/mysqld/mysqld.sock /tmp/mysql.sock能让旧脚本继续跑，但一旦服务重启、路径变更或权限重置，问题会悄悄回来
检查 socket 文件权限和父目录可写性
即使路径对了、服务也跑了，权限不对照样连不上——MySQL 进程（通常是 mysql 用户）必须对 socket 文件及其所在目录有读写权限。
- 确认 socket 文件存在后，运行：
ls -l /var/run/mysqld/mysqld.sock，输出中前段应类似srw-rw---- 1 mysql mysql（注意开头的s表示 socket 类型） - 检查父目录：
ls -ld /var/run/mysqld，必须是drwxr-xr-x 2 mysql mysql或更宽松；若属主不是mysql，运行sudo chown mysql:mysql /var/run/mysqld - 特别注意 SELinux（RHEL/CentOS）或 AppArmor（Ubuntu）：它们可能静默拒绝 socket 创建。临时关掉测试：
sudo setenforce 0或sudo systemctl stop apparmor，若问题消失，就得配策略而非关守护
真正麻烦的从来不是路径填错，而是服务启动失败后，你反复改 client 配置却始终无效——因为 mysql.sock 压根没机会被创建。所以排查顺序不能乱：先确保服务活了，再找它写的路径，最后让客户端对上号。中间任何一步跳过，都可能把 5 分钟能解决的问题拖成两小时。
