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 权限问题？
先定位真实生效的配置文件路径，再改权限：
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 查实际加载路径：
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——这些文件只要有一个权限超标，整个配置链就失效。
