如何解决MySQL 8.0中my.cnf配置文件权限过大造成无法启动？

MySQL 8.0会静默忽略world-writable的my.cnf（如chmod 766），因安全策略禁止others写入，仅留警告日志；须用chmod 644 + chown root:root修复，并确认实际加载路径及datadir、tmpdir权限与SELinux状态。

my.cnf 权限过大时，MySQL 8.0 会直接忽略该配置文件，导致启动失败——这不是警告，是静默跳过，服务按默认值硬扛，大概率崩在 datadir 或 tmpdir 上。

为什么 chmod 766 的 my.cnf 会导致启动失败？

Linux 安全策略强制要求：任何被 MySQL 加载的配置文件，都不能被“其他用户”（others）写入。一旦 ls -l my.cnf 显示权限含 w（如 -rw-rw-rw-、-rw-rw-r--），MySQL 就判定该文件不安全，直接跳过加载，连错误日志都不报——只留一句 Warning: World-writable config file '/etc/my.cnf' is ignored 在启动日志里，但很多人根本没查日志。

如何快速确认并修复 my.cnf 权限问题？

先定位真实生效的配置文件路径，再改权限：

• 查实际加载路径：mysqld --verbose --help 2>/dev/null | grep "Default options"，输出类似 Default options are read from the following files in the given order: /etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf
• 对每个路径执行 ls -l，重点看最后一位是否为 w（比如 rw-rw-rw-、rw-rw-r--）
• 仅保留属主可读写、属组和其他人只读：chmod 644 /etc/my.cnf（不要用 755 或 664）
• 确保属主是 root（非 mysql）：chown root:root /etc/my.cnf，否则 systemd 可能拒绝读取

修复后仍不生效？检查这三点

权限改对了，但服务还是起不来，往往卡在后续依赖上：

• datadir 目录权限未同步修正：即使 my.cnf 加载成功，若 datadir 属主不是 mysql:mysql 或权限不是 750，MySQL 仍会在初始化阶段报 Can't open the mysql.plugin table
• tmpdir 不可写：如果 my.cnf 里显式设了 tmpdir=/tmp，而 /tmp 挂载了 noexec,nosuid,nodev（CentOS 8+/Ubuntu 22.04+ 默认），MySQL 会因无法创建临时文件失败，且错误日志只显示 Permission denied，不提挂载选项
• SELinux/AppArmor 干预：sestatus 或 aa-status 若为 enforcing，即使文件权限全对，也可能拦截 mysqld 对 my.cnf 的读取，需补上下文或临时 setenforce 0 测试

真正容易被忽略的是：你改了 /etc/my.cnf，但 MySQL 实际读的是 /www/server/mysql/my.cnf（宝塔）、/etc/my.cnf.d/server.cnf（RHEL/CentOS 分片配置）或用户家目录下的 ~/.my.cnf——这些文件只要有一个权限超标，整个配置链就失效。