mysql 8.0 启动失败报 errcode: 13 通常是 selinux 上下文不匹配所致，需用 semanage 和 restorecon 永久修复，而非仅 chmod/chown；临时禁用 selinux（setenforce 0）可验证，audit.log 中 avc denied 日志可定位具体拦截路径。
看到 Errcode: 13 就先别碰 chmod 和 chown
MySQL 8.0 启动失败日志里出现 Can't create/write to file './ibdata1' (Errcode: 13) 或 Permission denied，八成不是权限数字没设对，而是 SELinux 拦住了。它根本不看 ls -ld 显示的 mysql:mysql，只认文件/目录的 security context。即使你刚执行过 chown -R mysql:mysql /var/lib/mysql，只要上下文还是 default_t 或 var_lib_t，mysqld 进程照样被拒绝写入。
用 getenforce 和 sestatus 快速坐实是不是 SELinux
别跳步，直接运行两行命令：
-
getenforce—— 输出Enforcing就基本锁定问题 -
sestatus—— 确认Current mode是enforcing，且Loaded policy name是targeted
再临时验证：执行 sudo setenforce 0，然后立刻 systemctl start mysqld。如果秒启成功，不用再往下查了——就是 SELinux 上下文不匹配。
修复必须用 semanage + restorecon，不能只靠 chcon
chcon -R -t mysqld_db_t /var/lib/mysql 只是临时打标，系统更新或重装后会丢失。生产环境必须走标准流程：
- 注册永久规则：
sudo semanage fcontext -a -t mysqld_db_t "/var/lib/mysql(/.*)?" - 批量修复上下文：
sudo restorecon -Rv /var/lib/mysql - 如果用了自定义数据目录（比如
/data/mysql），把路径换掉，同样执行上面两步 - socket 文件路径（如
/var/lib/mysql/mysql.sock）也要单独处理：sudo semanage fcontext -a -t mysqld_var_run_t "/var/lib/mysql/mysql\.sock"，注意点号要转义
audit.log 里藏着静默拦截的真实证据
有些拦截不会直接写进 MySQL 错误日志，得翻系统审计日志：
- 查最近的拒绝记录：
sudo ausearch -m avc -ts recent | grep mysqld - 或者直接搜：
sudo grep "avc.*denied" /var/log/audit/audit.log | tail -20
典型输出里会有 tcontext=unconfined_u:object_r:default_t:s0 —— 这说明目标路径被标成了通用类型，不是 mysqld 被允许访问的类型。漏掉一个路径（比如 /tmp/ib*、pid-file 所在目录、甚至 /etc/my.cnf.d/），就可能卡在初始化某一步，不报错也不启动。
