MySQL 8.0 启动失败因 /tmp 不可写，根本原因是系统级权限缺失而非配置错误；需确认 tmpdir 实际路径，优先改用专属目录如 /var/lib/mysql/tmp 并授权 mysql 用户，或修复 /tmp 的 SELinux 上下文及 systemd PrivateTmp 隔离问题。
MySQL 8.0 启动时因 /tmp 不可写直接失败，不是配置问题，是系统级权限缺失
MySQL 8.0 默认依赖 /tmp 但不自动创建或校验它
MySQL 8.0 在初始化或运行期间会频繁使用 /tmp（例如生成临时表、排序缓冲、SSL 临时密钥等）。但它不会主动创建该目录，也不检查其是否存在或是否可写——只要 mysqld 进程尝试写入失败，就会报类似：
Can't create/write to file '/tmp/ibXXXXX' (OS errno 13 - Permission denied)
或更隐蔽的：
Could not open /tmp/mysql.sock for writing: Permission denied
这类错误在 CentOS/RHEL 8+、Ubuntu 22.04+ 等较新系统上尤其常见，因为默认 /tmp 可能被挂载为 noexec,nosuid,nodev 或归属 root:root 且权限为 1777 但 MySQL 用户（如 mysql）仍被 SELinux 或 systemd-tmpfiles 机制限制。
手动创建 /tmp 并赋权前，先确认 MySQL 实际用哪个 tmp 目录
不要默认就去动系统 /tmp。先查 MySQL 配置中显式指定的路径：
- 检查
my.cnf或mysqld.cnf中是否有tmpdir设置：grep -i tmpdir /etc/my.cnf - 若没设置，MySQL 默认用
sys_gettempdir()返回值，在 Linux 上通常是/tmp；但某些打包版本（如 RHEL RPM）可能硬编码为/var/tmp - 运行中确认：连接 MySQL 后执行
SELECT @@tmpdir;
如果返回的是 /tmp 且你无法修改配置，才需要处理系统 /tmp；否则优先改 tmpdir 指向一个你可控的路径（如 /var/lib/mysql/tmp）。
给 /tmp 赋权的实操要点（避开常见坑）
直接 chmod 1777 /tmp 不够，MySQL 进程还需有“进入”和“写入”能力。关键步骤如下：
- 确保目录存在且归属正确：
sudo mkdir -p /tmp && sudo chown root:root /tmp && sudo chmod 1777 /tmp - MySQL 用户必须能写入：即使权限是
1777，SELinux 仍可能拦截——检查sudo ls -Z /tmp，若上下文不是tmp_t，运行sudo semanage fcontext -a -t tmp_t "/tmp(/.*)?" && sudo restorecon -Rv /tmp - systemd 系统需确认未启用
PrivateTmp=yes：检查systemctl show mysqld | grep PrivateTmp，若为yes，则 MySQL 实际看到的是隔离的/tmp（在/tmp/systemd-private-xxx-mysqld-xxx/tmp），此时改宿主/tmp无效，应改为在服务单元中禁用：sudo systemctl edit mysqld，加入[Service]\nPrivateTmp=no - 若用容器或非标准用户启动（如
docker run -u 1001），/tmp必须对该 UID 可写，不能只靠组权限
更稳妥的替代方案：不碰系统 /tmp，换一个专属目录
绕过所有权限争议的最简方式是让 MySQL 用自己专用的临时目录：
- 创建目录并授权：
sudo mkdir -p /var/lib/mysql/tmp && sudo chown mysql:mysql /var/lib/mysql/tmp && sudo chmod 750 /var/lib/mysql/tmp - 在
[mysqld]段添加：tmpdir = /var/lib/mysql/tmp - 重启服务：
sudo systemctl restart mysqld
这个路径天然归属 mysql 用户，不受 SELinux 默认策略干扰，也避开了 systemd 的 PrivateTmp 隔离，是最少副作用的选择。
真正容易被忽略的是：MySQL 8.0 对 tmpdir 的访问发生在进程早期初始化阶段，哪怕只是 mysqld --validate-config 也会触发——所以权限修复后务必用该命令验证，而不是直接 start 再等日志报错。
