selinux拦截问题本质是策略拒绝而非权限不足，排错须按“确认→定位→修复”三步：先用getenforce/sestatus验证模式，再通过ausearch/audit2why/sealert分析avc日志，最后针对文件标签、端口类型或布尔值错误修复，audit2allow仅作兜底。
看 getenforce 和 sestatus 就能快速锁定问题
执行 getenforce，输出 Enforcing 就基本可以断定是 SELinux 拦的；再跑 sestatus 确认 Current mode 是 enforcing，且 Loaded policy name 是 targeted。这两个命令比翻日志快得多，不用等 systemctl start mysqld 失败后再猜。
临时验证：setenforce 0 后立刻重试
运行 sudo setenforce 0（仅临时切换），马上执行 systemctl start mysqld。如果服务秒启成功，说明不是配置错、不是权限错、也不是磁盘满，就是 SELinux 上下文不匹配。注意：setenforce 0 不改任何文件，重启即恢复，只用来验证。
修复上下文：semanage + restorecon 才是正解
别用 chcon -R 临时打标签——它不会持久化，升级或重装后失效。必须走标准流程：
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
sudo semanage fcontext -a -t mysqld_db_t "/var/lib/mysql(/.*)?"sudo restorecon -Rv /var/lib/mysql- 如果改了
datadir（比如设成/data/mysql），把路径同步替换进上面两条命令 - 如果 socket 文件不在默认位置（如
/tmp/mysql.sock），也要加规则：sudo semanage fcontext -a -t mysqld_var_run_t "/tmp/mysql\.sock"，点号要转义
audit.log 里藏着真实拦截点
有些路径容易被忽略，比如 /tmp/ib*、自定义的 pid-file 路径、甚至 /var/log/mysql，SELinux 可能静默拒绝写入。查 /var/log/audit/audit.log 最直接：
sudo ausearch -m avc -ts recent | grep mysqld 或 sudo grep "avc.*denied" /var/log/audit/audit.log | grep mysqld
输出里 tcontext=... 那一栏显示的是目标路径当前的上下文类型，如果不是 mysqld_db_t（数据目录）或 mysqld_var_run_t（socket/pid），就说明漏标了。
Errcode: 13 或空行，根本看不出哪被拦了。
