errcode: 13 错误80%以上由selinux导致，先运行getenforce确认是否为enforcing模式，再用sestatus查看策略类型，临时执行setenforce 0验证；若mysql随即启动成功，即可确定是selinux上下文不匹配所致，而非传统权限问题。
80%以上的 MySQL 安装 Errcode: 13 错误，根源在 SELinux，不是目录权限没设对，而是上下文不匹配。
怎么快速确认是不是 SELinux 拦的？
别先改 chmod 或 chown——先看 SELinux 状态：
- 运行
getenforce：输出Enforcing就基本坐实了 - 运行
sestatus：确认策略类型（通常是targeted）和当前模式 - 临时验证：执行
sudo setenforce 0，再试systemctl start mysqld；如果立刻成功，就是它
为什么 chmod 644、chown mysql:mysql 还是报错？
因为 SELinux 不看传统权限，它看的是文件/目录的security context。即使 /var/lib/mysql 属主是 mysql:mysql，如果它的上下文不是 mysqld_db_t，mysqld 进程照样被拒绝写入。
- 查上下文：
ls -Z /var/lib/mysql，正常应含mysqld_db_t - 错误典型表现：
Can't create/write to file './ibdata1' (Errcode: 13)，但ls -ld显示权限完全正确 - 修复命令（数据目录）：
sudo semanage fcontext -a -t mysqld_db_t "/var/lib/mysql(/.*)?"，再sudo restorecon -Rv /var/lib/mysql - 同理处理配置目录：
sudo semanage fcontext -a -t mysqld_etc_t "/etc/mysql/conf.d(/.*)?"+restorecon
Docker 场景下挂载宿主机目录失败怎么办？
在启用了 SELinux 的宿主机上，用 -v /my/data:/var/lib/mysql 启动容器时，即使目录权限全开，也会因上下文继承失败被拒。
- 错误日志里看不到 SELinux 关键词，只显示
Permission denied或can't create ./ibdata1 - 根本原因是挂载后容器内路径继承了宿主机目录的 context（比如
unconfined_u:object_r:default_t:s0），而非mysqld_db_t - 解决方法一（推荐）：宿主机上先打标签：
sudo semanage fcontext -a -t mysqld_db_t "/my/data(/.*)?"→sudo restorecon -Rv /my/data - 解决方法二（运行时）：加
:z标签启动容器：docker run -v /my/data:/var/lib/mysql:z ...，让 Docker 自动重标上下文
SELinux 的难点不在“关不关”，而在“标不标对”。漏掉一个路径（比如 /tmp/ib* 或自定义的 pid-file 路径），就可能卡在某一步静默失败——查 audit.log 或用 ausearch -m avc -ts recent | grep mysqld 才能暴露真实拦截点。
