MySQL启动时强制校验my.cnf权限，仅允许644或600；若组可写（如640）则直接拒绝启动，导致服务失败、配置不加载；需检查所有可能加载路径的权限并统一修复。
my.cnf 文件权限必须是 644 或 600，不能是 640
MySQL 启动时会校验 my.cnf（或 mysqld.cnf）的文件权限，如果组可写（即权限含 2，如 640、664），它会直接拒绝启动并报错：World-writable config file '/etc/mysql/my.cnf' is ignored。这不是警告，是硬性拒绝。
常见错误现象：
- MySQL 服务反复失败，
systemctl status mysql显示 “failed to start” -
mysqld --defaults-file=/etc/mysql/my.cnf --verbose --help报相同 world-writable 错误 - 配置里明明写了
bind-address = 0.0.0.0，但 netstat 看不到 3306 监听 —— 因为配置根本没加载
实操建议：
- 用
ls -l /etc/mysql/my.cnf检查当前权限，重点关注第三位（组权限）和最后一位（其他权限） - 修复命令统一用：
sudo chmod 644 /etc/mysql/my.cnf（推荐，兼容大多数部署） - 若该文件属主是
mysql且仅由 MySQL 进程读取，也可用sudo chmod 600 /etc/mysql/my.cnf（更严格，但需确认 systemd service 文件中User=设置匹配） - 切勿用
755、640、664—— 组可写或全局可执行都会触发拒绝
多个配置文件共存时，权限检查覆盖全部路径
MySQL 实际按固定顺序扫描多个路径（如 /etc/my.cnf、/etc/mysql/my.cnf、~/.my.cnf），只要其中任一存在且权限不合规，就会跳过整个文件，甚至可能静默忽略后续配置项。
使用场景：
- 你改了
/etc/mysql/my.cnf，但忘记/etc/my.cnf还残留着旧文件 - 开发环境在 home 目录下放了
~/.my.cnf，权限设成644，但属组是staff且该组有其他用户 —— MySQL 仍会因“group-writable”拒绝它
实操建议：
- 运行
mysqld --verbose --help | grep "Default options"查看实际加载路径列表 - 对每个路径执行
ls -l，逐个确认权限；不存在的文件不用管，但存在的必须合规 - 临时排除干扰：把疑似问题的配置文件重命名（如
mv /etc/my.cnf /etc/my.cnf.bak），再试启动
systemd 下修改权限后必须 reload，不是 restart
改完 my.cnf 权限后，如果只执行 sudo systemctl restart mysql，有时会卡在 “activating (start)” 状态或报 “timeout”。这是因为 systemd 的 unit 文件可能设置了 ProtectHome=true 或 RestrictSUIDSGID=true，而权限变更触发了内部安全检查缓存未刷新。
性能 / 兼容性影响：
-
restart会先 stop 再 start，期间服务中断；而reload不中断连接，但前提是 mysqld 支持平滑重载（实际仅部分配置项生效，权限本身不在此列） - 真正起效的是
daemon-reload + restart组合，而非单次 restart
实操建议：
- 改完权限后，先运行：
sudo systemctl daemon-reload - 再运行：
sudo systemctl restart mysql - 验证是否加载成功：
mysql -e "SELECT @@version_compile_os, @@config_file;"，并检查@@config_file输出是否是你刚修的路径
Docker 容器内 my.cnf 权限容易被 volume 覆盖
用 -v /host/my.cnf:/etc/mysql/my.cnf:ro 挂载时，宿主机文件权限会透传进容器。但 MySQL 容器启动用户通常是 mysql（uid 999），若宿主机上 my.cnf 属主不是 uid 999 且权限宽松（比如 644），MySQL 仍会因“other-writable”拒绝 —— 注意：即使挂载为 ro，权限检查照常发生。
常见错误现象：
- 本地
docker run成功，CI 流水线跑失败，因为 CI 机器上文件属组不同 - Mac 上用 Docker Desktop 挂载，文件默认属组是
staff，MySQL 容器内无此组，权限判定逻辑异常
实操建议：
- 宿主机上统一用：
sudo chown root:root /path/to/my.cnf && sudo chmod 644 /path/to/my.cnf - 避免用
~或相对路径挂载，全部用绝对路径，防止不同环境解析差异 - 更稳妥的做法：把配置内容写进 Dockerfile 的
COPY指令，由构建过程控制权限（COPY --chown=mysql:mysql不适用，因为配置文件必须 root 可读）
