mysql.sock路径不一致是客户端与服务端套接字位置不匹配所致，核心解法是统一配置文件中[mysqld]、[client]、[mysql]三处socket路径并重启服务，软链接仅作临时应急。
mysql.sock 路径不一致是最常见原因
错误提示里出现的 /tmp/mysql.sock、/var/lib/mysql/mysql.sock 或 /storage/db/mysql/mysql.sock，基本都是客户端和服务端对 socket 文件位置“各说各话”导致的。服务端按配置生成 sock 文件，客户端却默认去别处找——哪怕 mysqld 进程明明在跑，也会报这个错。
核心判断方式：先确认服务端实际生成的 sock 文件在哪，再让客户端去同一位置找。不要假设路径，必须查实。
- 用
netstat -ln | grep mysql查监听的 Unix 域套接字路径（如果显示的是mysql而非具体路径，说明没走 socket，可能在用 TCP） - 用
ps aux | grep mysqld看启动命令是否带--socket=参数，优先级高于配置文件 - 检查
mysqld --verbose --help 2>/dev/null | grep "socket"输出的默认值和当前生效值
修改 /etc/my.cnf 必须覆盖三个 section
只改 [mysqld] 下的 socket 不够，客户端工具（如 mysql 命令、PHP 的 mysqli）会分别读取 [client] 和 [mysql] 的配置。漏掉任意一个，就可能 fallback 到默认路径。
正确写法示例（路径需与服务端一致）：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
[mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock <p>[client] socket=/var/lib/mysql/mysql.sock</p><p>[mysql] socket=/var/lib/mysql/mysql.sock
-
[client]影响所有客户端程序（包括mysql、mysqldump） -
[mysql]专用于mysql命令行客户端，可覆盖[client]中的部分设置 - 修改后必须重启
mysqld：执行systemctl restart mysqld或service mysqld restart
中文字符或空格会导致配置静默失效
看似正常的配置文件，如果混入中文破折号、全角空格、不可见 Unicode 字符（比如从网页复制粘贴），MySQL 会直接忽略整行，不报错也不警告。结果就是你改了配置，但实际没生效。
- 用
cat -A /etc/my.cnf检查是否有^M（Windows 换行）、M-bM-^@M-^类乱码 - 确保
=两侧无空格，且是英文等号，不是中文＝ - 避免在配置项末尾加注释（如
socket=/path/to.sock # 注释），MySQL 不支持行内注释
软链接只是临时补救，不是根本解法
当无法立刻修改配置时，建软链接确实能快速绕过问题：ln -sf /var/lib/mysql/mysql.sock /tmp/mysql.sock。但它掩盖了配置不一致的本质，而且一旦服务端路径变更或权限收紧，链接会立即失效。
更麻烦的是：某些容器环境或 systemd 启动脚本会清理 /tmp，导致链接被删；SELinux 策略也可能阻止跨目录访问软链接。
- 仅建议用于调试或紧急恢复，不要写入部署文档
- 检查软链接是否有效：
ls -l /tmp/mysql.sock看目标是否存在且可读 - 确认 mysqld 进程用户（通常是
mysql）对源路径和链接路径都有读写权限
真正卡住的地方往往不在配置本身，而在于「你以为改了，其实没生效」——比如编辑的是 /etc/my.cnf，但 mysqld 实际加载的是 /usr/my.cnf 或 ~/.my.cnf；又或者你改了配置，却忘了重启服务，甚至重启的是错误的服务名（mysql vs mysqld）。
