MySQL 启动失败且报 Permission denied
错误，大概率是 SELinux 拦的
CentOS/RHEL 8+ 默认启用 SELinux，而 MySQL 的默认安装路径（如
/var/lib/mysql）、socket 文件（
/var/lib/mysql/mysql.sock）、配置文件（
/etc/my.cnf）等，若被修改过位置或权限，SELinux 会阻止 mysqld 进程访问——即使
ls -l看权限完全正确。典型现象是：
systemctl start mysqld瞬间退出，
journalctl -u mysqld -n 50里出现
avc: denied记录。 先确认状态：
sestatus—— 若输出
enabled且
current mode是
enforcing，就需处理 SELinux 临时放行（仅调试用）：
setenforce 0，再试启动；若成功，基本锁定是 SELinux 策略问题 不要直接永久禁用（
sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config），这等于放弃系统级安全防护
给 MySQL 目录和 socket 打上正确的 SELinux 上下文
MySQL 官方 RPM 包已内置基础策略，但手动部署、自定义数据目录（比如改到
/data/mysql）、或升级后重装，上下文常丢失。必须用
semanage fcontext注册路径，再用
restorecon生效，不能只靠
chcon临时改。 标准数据目录修复：
semanage fcontext -a -t mysqld_db_t "/var/lib/mysql(/.*)?"，然后
restorecon -Rv /var/lib/mysql若用了自定义路径（如
/data/mysql）：
semanage fcontext -a -t mysqld_db_t "/data/mysql(/.*)?"，再
restorecon -Rv /data/mysqlsocket 文件路径也要匹配：
semanage fcontext -a -t mysqld_var_run_t "/var/lib/mysql/mysql\.sock"，再
restorecon -v /var/lib/mysql/mysql.sock注意正则写法中的转义：点号要写成
\.，否则规则不生效
mysqld 无法绑定非标准端口（如 3307）？检查 mysqld_port_t
是否授权
MySQL 默认监听
3306，SELinux 允许该端口。若在
my.cnf中改成
port = 3307，服务可能启动但客户端连不上，
journalctl出现
avc: denied for name="3307" ... scontext=system_u:system_r:mysqld_t:s0。这是因为
3307不在
mysqld_port_t类型的允许列表里。 查当前允许端口：
semanage port -l | grep mysqld添加新端口：
semanage port -a -t mysqld_port_t -p tcp 3307删错的端口（谨慎）：
semanage port -d -t mysqld_port_t -p tcp 3307改完无需重启 mysqld，SELinux 策略实时生效
audit2why 和 audit2allow 是排障核心工具，别跳过
光看
avc denied日志不够直观。SELinux 拒绝记录在
/var/log/audit/audit.log（或
journald），直接读很费劲。用
audit2why能把拒绝事件翻译成自然语言原因，用
audit2allow可生成最小化策略模块。 快速分析最近拒绝：
ausearch -m avc -ts recent | audit2why生成并安装自定义策略（例如因插件目录引发的拒绝）：
ausearch -m avc -ts recent | audit2allow -M mysql_custom，然后
semodule -i mysql_custom.pp策略模块名（
mysql_custom）不能含下划线或特殊字符，否则
semodule报错 生成的
.pp文件是二进制策略，别手改；调试阶段建议加
-D参数看原始规则（
audit2allow -D -M xxx）
SELinux 不是“开关题”，关键在上下文类型与策略规则的精准匹配。漏掉一个
restorecon或端口授权，MySQL 就可能静默失败。运维 MySQL 时，
sestatus和
ausearch应该和
systemctl status一样成为条件反射式操作。
