MySQL启动报Errcode:13或Permission denied八成是SELinux上下文不匹配所致；先用getenforce和sestatus确认Enforcing模式，再执行setenforce 0临时验证，若启动成功即证实问题，最后用semanage fcontext注册mysqld_db_t等类型并restorecon -Rv修复上下文。
MySQL 启动报 Errcode: 13 或 Permission denied，八成是 SELinux 拦的，不是权限没设对，而是上下文类型错了。
怎么快速确认是不是 SELinux 在拦？
别急着 chown 或 chmod —— 先看状态：
- 运行
getenforce：输出Enforcing就基本坐实了 - 运行
sestatus：确认Current mode是enforcing，且Loaded policy name是targeted - 临时验证：执行
sudo setenforce 0，再试systemctl start mysqld；如果立刻成功，就是 SELinux 上下文问题
setenforce 0 只是临时切换，重启后失效，仅用于验证。它不改任何文件，只关策略 enforcement。
为什么 chown mysql:mysql 还是报错？
因为 SELinux 不看传统用户组权限，它检查的是文件/目录的 security context。即使 /var/lib/mysql 属主正确，若上下文不是 mysqld_db_t，mysqld 进程照样被拒绝写入。
- 查当前上下文：
ls -Z /var/lib/mysql，正常应含mysqld_db_t - 典型错误日志：
Can't create/write to file './ibdata1' (Errcode: 13)，但ls -ld显示权限完全正确 - audit 日志里会出现：
avc: denied { write } tcontext=unconfined_u:object_r:default_t:s0，说明目标类型是default_t而非mysqld_db_t
如何修复 SELinux 上下文？
必须用 semanage fcontext 注册规则，再用 restorecon 生效——不能只靠 chcon 临时改，否则升级或重装后丢失。
- 标准数据目录：
sudo semanage fcontext -a -t mysqld_db_t "/var/lib/mysql(/.*)?"，然后sudo restorecon -Rv /var/lib/mysql - 自定义数据目录（如
/data/mysql）：sudo semanage fcontext -a -t mysqld_db_t "/data/mysql(/.*)?"，再restorecon -Rv /data/mysql - socket 文件路径（如
/var/run/mysqld/mysqld.sock）：sudo semanage fcontext -a -t mysqld_var_run_t "/var/run/mysqld/mysqld\.sock"（点号要转义），再sudo restorecon -v /var/run/mysqld/mysqld.sock - 非标端口（如
port = 3307）需授权：sudo semanage port -a -t mysqld_port_t -p tcp 3307
漏掉一个路径（比如 /tmp/ib*、/var/log/mysql/ 或自定义 pid-file 路径），就可能卡在某一步静默失败——得查 /var/log/audit/audit.log 或用 ausearch -m avc -ts recent | grep mysqld 才能暴露真实拦截点。
