mysql 8.0 启动失败因 tmpdir 权限拒绝，根本原因是系统级限制（如 privatetmp、selinux 或 /tmp 挂载选项），而非 mysql 配置错误；应优先使用专用 tmpdir 路径并验证 mysql 用户可写。
MySQL 8.0 启动失败时，报错里出现 /tmp/ibXXXXX 或 /tmp/mysql.sock 权限拒绝，基本就是它卡在临时目录上——不是配置写错了，是系统根本不让 mysqld 进程往那个路径写东西。
tmpdir 默认值和实际路径不一致，查之前别瞎改
MySQL 启动时根本不会主动创建 tmpdir 目录，也不校验可写性，只管用。它先看配置：
- 如果
my.cnf里显式写了tmpdir，就用那个； - 没写，则调用系统函数
sys_gettempdir()，Linux 上通常返回/tmp，但某些发行版（如 RHEL RPM 包）会硬编码成/var/tmp。
所以第一步必须确认真实路径：
- 查配置：
grep -i tmpdir /etc/my.cnf - 连上去看运行时值：
SELECT @@tmpdir;（前提是能连上；连不上就跳过这步）
别一上来就 chmod 777 /tmp，很多新系统（CentOS 8+、Ubuntu 22.04+）默认挂载 /tmp 带 noexec,nosuid,nodev，或者受 SELinux / systemd PrivateTmp 隔离限制，chmod 无效。
/tmp 不可写的真实原因：SELinux、systemd 或挂载选项
常见错误现象：
- 日志里反复出现：
Can't create/write to file '/tmp/ibXXXXX' (OS errno 13 - Permission denied) - 或更隐蔽的：
Could not open /tmp/mysql.sock for writing: Permission denied
这不是 MySQL 的 bug，是系统级约束：
-
systemd启动 mysqld 时若启用了PrivateTmp=yes（RHEL/CentOS 默认），进程看到的/tmp其实是隔离沙箱，MySQL 自己进不去 - SELinux 上下文不对，比如
/tmp是tmp_t，但 mysqld 被策略限制只能写mysqld_tmp_t -
/tmp挂载时加了noexec或nodev，部分临时文件操作（如 SSL 密钥生成）会失败
验证方式：
-
ls -Z /tmp看 SELinux 类型 systemctl show mysqld | grep PrivateTmpmount | grep tmp
推荐做法：绕开系统 /tmp，用专属目录
最稳的解法不是修 /tmp，而是让 MySQL 用自己可控的路径：
- 创建专用目录：
sudo mkdir -p /var/lib/mysql/tmp - 授权给 mysql 用户：
sudo chown mysql:mysql /var/lib/mysql/tmp - 在
my.cnf的[mysqld]段落加一行：tmpdir = /var/lib/mysql/tmp - 重启服务前，确认目录权限无误：
sudo -u mysql touch /var/lib/mysql/tmp/test（能写才真有效）
如果必须用 /tmp，优先检查并禁用 PrivateTmp（修改 /usr/lib/systemd/system/mysqld.service），而不是强行改 SELinux 策略或挂载参数——后者容易引发其他服务异常。
关键点其实就一个：MySQL 8.0 对 tmpdir 完全零容错，它不检查、不提示、不 fallback，写失败就直接 abort。你看到的服务“启动后立刻停止”，八成就卡在这一步。别在日志里翻来覆去找插件加载失败或密码错误，先盯住 @@tmpdir 和对应路径的写权限。
