先运行getenforce，若输出Enforcing；再执行sestatus确认Current mode为enforcing且Policy MLS status enabled；最后sudo setenforce 0 && systemctl start mysqld，若成功即锁定SELinux拦截。
直接看 getenforce 输出，是 Enforcing 就基本可以锁定 SELinux —— 80% 以上的 Errcode: 13 或 Permission denied 不是权限没给对，而是上下文不匹配。
怎么快速确认是 SELinux 拦的，而不是配置或权限问题？
别急着改 my.cnf、别反复 chown 或 chmod。先跑这三行：
-
getenforce：输出Enforcing就高度可疑 -
sestatus：确认Current mode:是enforcing，且Policy MLS status:是enabled（通常是targeted） -
sudo setenforce 0 && systemctl start mysqld：如果秒启成功，就是它；setenforce 0是临时切到 permissive 模式，只记录不拦截，不影响其他服务
补充验证（可选但更准）：ausearch -m avc -ts recent | grep mysqld，有输出即实锤；若提示命令未找到，先装 audit 工具（yum install audit 或 apt install auditd）。
为什么 /var/lib/mysql 属主属组全对还报错？
因为 SELinux 不看 ls -l，它看的是安全上下文（security context）。即使目录属于 mysql:mysql，只要类型不是 mysqld_db_t，mysqld 进程照样被拒绝写入。
- 查当前上下文：
ls -Z /var/lib/mysql，正常应含mysqld_db_t；若显示default_t、var_t或unconfined_u:object_r:default_t:s0，说明标错了 - 临时修复（重启失效）：
sudo 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 - 漏掉
(/.*)?是常见错误——只改了目录本身，子目录仍是错的上下文
Docker 挂载宿主机目录失败怎么办？
在启用 SELinux 的宿主机上，docker run -v /my/data:/var/lib/mysql 即使权限全开也会静默失败。根本原因是容器内路径继承了宿主机目录的原始上下文（比如 default_t），而非 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；多容器共享用:Z - 别忘了临时路径：比如
/tmp/ib.*或自定义pid-file路径，也得单独打标，否则可能卡在某一步无日志报错
哪些布尔值可能让 MySQL 功能受限？
有些操作默认被 SELinux 策略禁止，光打标签还不够。查当前设置：getsebool -a | grep mysqld。
-
mysqld_can_network：远程访问必需，否则连不上 3306 -
mysqld_connect_any：允许SELECT ... INTO OUTFILE写网络路径等场景 - 开启方式：
sudo setsebool -P mysqld_can_network on（-P表示永久生效）
真正难的不是关不关 SELinux，而是标不标对——漏一个路径、少一个布尔值，就可能没有任何明确报错，只看到 mysqld 启动后立刻退出（status=1），而错误日志里连 AVC 关键词都不出现。
