mysql启动时严格校验配置文件权限，仅接受644或600；600需确保运行用户（如mysql）有读权，否则启动失败；必须检查所有默认路径（如/etc/my.cnf、/etc/mysql/my.cnf等）并统一修复权限，且修改后须执行systemctl daemon-reload再reload或restart服务。
直接设成 chmod 600 /etc/my.cnf 很可能让 MySQL 启动失败——不是权限太松，而是太严，且违反了 mysqld 的硬性校验规则。
MySQL 启动时会拒绝加载组可写或权限不合规的 my.cnf
mysqld 在启动阶段会主动检查所有被加载的配置文件（如 /etc/my.cnf、/etc/mysql/my.cnf、~/.my.cnf）的权限。只要其中任一文件权限含“组可写”（比如 640、664）或“全局可写”（602 等），它就会静默跳过该文件，并报错：
World-writable config file '/etc/mysql/my.cnf' is ignored
这不是警告，是 fatal 错误：配置不生效、服务无法启动、bind-address 不监听、max_connections 用默认值……你改的所有东西都白调。
- 必须满足：权限只能是
644或600（仅此两种） -
640、755、664、777全部被拒 - 属主可以是
root或mysql，但属组不能有写权限 - 用
ls -l /etc/my.cnf看第三位字符：如果是w（如-rw-rw-r--），就铁定失败
为什么 chmod 600 /etc/my.cnf 仍可能出问题
600 虽然满足 mysqld 的权限校验，但它把读权限只给了 root，而实际运行 mysqld 的用户通常是 mysql（由 systemd 的 User=mysql 指定）。如果该用户无权读取配置文件，进程会因 Can't read from file '/etc/my.cnf' 直接退出。
- 先确认 mysqld 运行身份：
systemctl show --property=User mysql或查/lib/systemd/system/mysqld.service - 若
User=mysql，则600下mysql用户完全不可读 → 启动失败 - 此时正确权限应为
644（root:root或root:mysql均可），确保mysql用户能读 - 若坚持用
600，必须同时设chown mysql:mysql /etc/my.cnf，但此举反而扩大了可写范围，不推荐
必须检查所有可能被加载的 my.cnf 路径
MySQL 按固定顺序扫描多个路径，只要其中任意一个存在且权限不合规，整个配置链就中断。常见路径包括：
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
/etc/my.cnf-
/etc/mysql/my.cnf（Debian/Ubuntu 默认） /usr/etc/my.cnf-
~/.my.cnf（危险！常含明文密码）
执行以下命令确认实际搜索路径：
mysqld --verbose --help | grep "Default options"
对每个输出路径做两件事：
- 若文件存在：
ls -l <path></path>检查权限是否为644或600 - 若文件存在但权限不对：用
sudo chmod 644 <path></path>统一修复 - 若文件存在但你不用它（如残留的
/etc/my.cnf），直接删或重命名（mv /etc/my.cnf /etc/my.cnf.disabled）
修复后必须 reload systemd 配置，不能只 restart
改完权限后，仅执行 sudo systemctl restart mysql 可能卡在 “activating (start)” 或超时。因为 systemd 的 unit 文件（如 ProtectHome=true）会在权限变更后触发安全缓存重检，需显式刷新。
- 先 reload unit 配置：
sudo systemctl daemon-reload - 再 reload 服务（不中断连接）：
sudo systemctl reload mysql（前提是 mysqld 支持平滑重载） - 若 reload 失败或不支持，再用
sudo systemctl restart mysql - 验证是否生效：
sudo systemctl status mysql+ 查sudo tail -n 20 /var/log/mysql/error.log
真正容易被忽略的是：权限问题从来不是单点问题。你盯住 /etc/my.cnf，却忘了 /etc/mysql/my.cnf 或 ~/.my.cnf 也在加载链里；你设对了权限，却没 reload systemd；你修好了文件权限，却没关掉 SELinux/AppArmor 的路径限制——这些都足以让服务反复失败，而错误日志里只有一句模糊的 “config file is ignored”。
