“bind on unix socket”错误主因是bind系统调用失败，分三类：地址已被占用（查残留mysqld进程）、父目录不存在或权限不足（建目录并chown mysql:mysql）、客户端与服务端socket路径配置不一致（需my.cnf中[mysqld]与[client]段完全匹配）。
“Bind on unix socket”错误不是因为 sock 文件被删了
删掉 /tmp/mysql.sock 本身不会导致 MySQL 启动失败——mysqld 启动时会自动创建它。真正卡住的是 bind 系统调用失败，错误信息里的 “Address already in use” 或 “No such file or directory” 或 “Permission denied” 指向三个不同方向，不能一概而论。
常见误操作是看到报错就去删 sock 文件、重启服务，结果反复失败。关键得先判断：是地址被占？目录不存在？还是权限不够？
检查是否有残留 mysqld 进程在监听 socket
当错误含 Address already in use，说明内核认为那个 socket 地址（路径）已被占用，最常见原因是旧进程没彻底退出，还在持有该路径的文件描述符。
- 运行
lsof -U | grep mysql或ss -xl | grep mysql查看是否已有进程绑定了目标 socket 路径 - 用
ps aux | grep mysqld找出疑似残留进程，注意看启动命令里的--socket=参数或配置文件中socket值 - 别只杀名字带 mysqld 的进程——有些是监控脚本或代理，得结合
lsof输出确认 PID 和实际路径 - 强制 kill 后，等几秒再
systemctl start mysqld，避免 systemd 认为上一次启动还没 clean up 完
验证 socket 路径对应目录是否存在且权限正确
错误含 No such file or directory 或 Permission denied，大概率是 socket 配置指向的父目录不存在，或属主/权限不满足 mysqld 写入要求。
- 查真实 socket 路径：
mysqld --print-defaults | grep socket，或翻/etc/my.cnf、/etc/mysql/my.cnf里[mysqld]段的socket行 - 比如配置是
socket = /var/run/mysqld/mysqld.sock，那就执行：ls -ld /var/run/mysqld—— 若提示 “No such file”，需手动建目录：mkdir -p /var/run/mysqld - 属主必须是运行 mysqld 的用户（通常是
mysql）：chown mysql:mysql /var/run/mysqld - 目录权限建议
755，不要777；尤其在启用了 SELinux 或 AppArmor 的系统上，chmod 777可能触发策略拒绝
确认 my.cnf 中 client/server socket 路径一致
MySQL 客户端和服务器通过 socket 文件通信，但它们各自读取不同配置段。如果 [mysqld] 和 [client]（或 [mysql]）里 socket 值不一致，会导致启动成功但本地连接失败，日志里也可能出现误导性 bind 错误。
- 运行
mysql --help | grep "Default options"看客户端加载哪些配置文件 - 检查
[mysqld]段的socket和[client]段的socket是否完全相同（包括路径和文件名） - 例如：
[mysqld] socket=/tmp/mysql.sock，那[client] socket=/tmp/mysql.sock也必须存在；否则mysql -u root会连错位置，甚至触发服务器端因冲突重试 bind - macOS 上 Homebrew 安装常默认用
/usr/local/var/mysql/mysql.sock，但客户端可能仍找/tmp/mysql.sock，这类不匹配必须手动对齐
最容易被忽略的是：socket 路径是否落在被挂载选项限制的目录下。比如 /tmp 被挂为 noexec,nodev，或 /var/run 是 tmpfs 且空间不足，这些都不会直接报错“no space left”，而是静默失败在 bind 阶段。
