mysql 8.0+ 遇到 world-writable 的 my.cnf（如777/766）会静默忽略该文件，仅在日志中记录警告，导致按默认参数启动而失败；须用 mysqld --verbose --help 查真实加载路径，再 chmod 644 + chown root:root 修复，并检查 datadir、tmpdir 权限及 selinux 状态。
my.cnf权限为777/766时MySQL直接跳过加载
MySQL 8.0+ 遇到 world-writable 的 my.cnf（如 -rwxrwxrwx 或 -rw-rw-rw-）会静默忽略该文件，不报错、不中断启动流程，只在日志里写一句 World-writable config file '/etc/my.cnf' is ignored。结果是服务按默认参数硬扛，大概率卡在 datadir 或 tmpdir 权限上，报 Can't open the mysql.plugin table 或 Permission denied 这类看似无关的错误。
怎么确认MySQL实际读的是哪个my.cnf
别凭经验改 /etc/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--） - 宝塔用户注意：
/www/server/mysql/my.cnf；RHEL/CentOS 用户注意：/etc/my.cnf.d/server.cnf这类分片配置文件也受同样限制
修复权限必须同时满足三个条件
光 chmod 644 不够，缺一不可：
-
chmod 644 /path/to/my.cnf（不能用664或755，others 必须无写权限） -
chown root:root /path/to/my.cnf（属主必须是root，不是mysql；systemd 会拒绝读取非 root 属主的配置） - 确认 SELinux 状态：
sestatus若为enforcing，需补上下文或临时setenforce 0测试
修复后仍启动失败？检查后续依赖项
配置文件能加载了，不代表服务就能跑起来。常见断点：
-
datadir目录权限：必须chown -R mysql:mysql /var/lib/mysql+chmod 750 /var/lib/mysql -
tmpdir是否挂载了noexec？比如/tmp在 CentOS 8+/Ubuntu 22.04+ 默认带nodev,nosuid,noexec，MySQL 无法创建临时文件 - 配置里写的路径是否真实存在？比如
log-error = /var/log/mysql/error.log，但/var/log/mysql目录不存在或mysql用户无写权限
/etc/my.cnf 改了半天，MySQL 却在读 /etc/my.cnf.d/server.cnf ——只要链上任一文件权限超标，整个配置就作废。
