mysql的socket路径必须在[mysqld]和[client]段同时声明绝对路径，如socket = /data/mysql/mysql.sock，且目录需提前创建并属主为mysql:mysql，否则服务端与客户端将因路径不一致而连接失败。
mysql配置文件里怎么写socket路径
MySQL的socket路径必须在[mysqld]和[client]两个段落中**同时声明**，否则服务端和客户端会各自用默认值，导致“找不到文件”或“权限拒绝”。比如你改了[mysqld]的socket，但没同步改[client]，命令行mysql -u root仍会去找/tmp/mysql.sock。
典型写法：
[mysqld] socket = /data/mysql/mysql.sock [client] socket = /data/mysql/mysql.sock
注意：/data/mysql/目录必须**提前创建好**，且属主是运行mysqld的用户（通常是mysql:mysql）。如果目录不存在，mysqld启动后不会报错，但mysql.sock根本不会生成。
常见错误点：
-
[client]段漏写，或写成[mysql]——后者只影响mysql命令行工具，不影响mysqldump、xtrabackup等其他客户端 - 路径用了相对路径（如
./mysql.sock），MySQL只认绝对路径 - 路径中包含空格或特殊字符（如
/var/run/mysqld (v2)/），会导致启动失败且日志不明确
为什么chmod 777不是解决socket权限的正解
给mysql.sock或其父目录设chmod 777确实能绕过“Permission denied”，但这是临时掩盖问题，且有安全风险：任何用户都能删除或覆盖该文件，导致连接中断甚至服务不可用。
真正要修复的是**进程与文件的归属关系**：
-
mysqld进程必须由mysql用户启动（不能用root直接跑） -
socket文件所在目录（如/data/mysql/）需chown mysql:mysql，且权限至少为755 -
mysql.sock文件本身权限通常为777或666，但这是mysqld自动设置的，无需手动干预
验证方式：
ps aux | grep mysqld 看启动用户；ls -ld /data/mysql 看目录权限；ls -l /data/mysql/mysql.sock 看文件是否存在、属主是否匹配。
PHP/Python应用连不上socket时该查哪几处
PHP 和 Python 的 MySQL 驱动**完全不读取my.cnf中的[client]段**。即使你把socket路径配得再准，它们也视而不见。
必须显式指定：
- PHP 中：
mysqli.default_socket或pdo_mysql.default_socket要在php.ini里写死，路径必须和my.cnf一致；或者代码里用mysqli_init()+mysqli_real_connect($link, null, ...)传NULL作为host，并在mysqli_options()里设MYSQLI_OPT_UNIX_SOCKET - Python 中：
pymysql.connect(unix_socket='/data/mysql/mysql.sock', ...)——host='localhost'在这里无效，必须传unix_socket参数 - Docker 场景下更麻烦：容器内
/data/mysql/mysql.sock和宿主机路径不同，别硬映射；优先用host.docker.internal走 TCP，或挂载宿主机 socket 文件并确保 UID/GID 匹配
xtrabackup或mysqldump报socket错误怎么办
xtrabackup、mysqldump、mysqladmin这些工具默认只认my.cnf里的[client]段，但容易被环境变量或命令行参数覆盖。最稳妥的做法是：在命令中**显式加--socket参数**。
例如：
xtrabackup --backup --target-dir=/backup/ --user=root --password=xxx --socket=/data/mysql/mysql.sock
注意：--socket必须写在--user和--password之后，否则会被忽略；如果路径含空格，要用引号包裹。
另一个易忽略点：xtrabackup需要访问datadir下的所有文件，所以不仅socket路径要对，datadir目录权限也得让xtrabackup进程可读——常被SELinux或AppArmor拦截，此时看dmesg比看MySQL日志更直接。
