MySQL启动失败是因为640权限中组可写（第二位为w），触发其硬性安全校验，仅允许644或600权限；需检查所有配置路径并统一修复。

为什么 chmod 640 /etc/my.cnf 会导致 MySQL 启动失败

MySQL 启动时会主动拒绝加载任何「组可写」的配置文件，640 的权限中第二位是 w（即 group-writable），触发硬性校验失败。错误日志里不会显示“permission denied”，而是静默跳过并报：World-writable config file '/etc/my.cnf' is ignored。这不是警告，是 fatal 错误：所有配置不生效，bind-address、max_connections 等全回退默认值。

• 用 ls -l /etc/my.cnf 检查第三列字符，只要出现 w（如 -rw-rw-r-- 或 -rw-rw----），就一定被拒
• 640、664、755、777 全部不合法；只接受 644 和 600
• 即使你只改了 /etc/mysql/my.cnf，但 /etc/my.cnf 还存在且权限违规，整个加载链也会中断

chmod 600 不行，那到底该设成什么权限

必须同时满足两个条件：MySQL 进程能读、且权限通过校验。而 600 虽然合规，但若属主不是运行用户（通常是 mysql），进程就读不到——Can't read from file '/etc/my.cnf' 直接退出。所以不能只看数字，要看谁在跑 mysqld。

Pandas 配置文件报告生成器

使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。

下载

• 先确认运行身份：systemctl show --property=User mysql，多数生产环境返回 User=mysql
• 若 User=mysql，chmod 600 /etc/my.cnf 必须配 chown mysql:mysql /etc/my.cnf，但此举让 mysql 用户可写，违背最小权限原则
• 更稳妥做法：chown root:mysql /etc/my.cnf && chmod 644 /etc/my.cnf —— root 可写，mysql 组可读，其他用户无权碰
• 注意：如果系统启用了 ProtectHome=true 或 RestrictSUIDSGID=true，改完权限后必须执行 systemctl daemon-reload，再 systemctl restart mysql

不止 /etc/my.cnf，这些路径也得一起查

MySQL 按固定顺序扫描多个配置路径，只要其中任意一个存在且权限不合规，就会中断加载。只修 /etc/my.cnf 是白忙——比如 /etc/mysql/my.cnf 或 ~/.my.cnf 留着，照样出问题。

• 查真实加载路径：mysqld --verbose --help | grep "Default options"
• 常见路径包括：/etc/my.cnf、/etc/mysql/my.cnf、/usr/etc/my.cnf、~/.my.cnf
• ~/.my.cnf 尤其危险：开发机上常含明文密码（[client] password=xxx），且普通用户可写可读，必须删或设为 600 并 chown $USER:$USER
• 对每个存在的路径执行：ls -l → 权限非 644/600 就立刻修复，不存在的不用管

进阶防护：chattr +i 和 secure_file_priv 不是万能的

chattr +i /etc/my.cnf 确实能防篡改，但它会让所有自动化操作（如 mysql_secure_installation、某些 RPM 升级脚本）失败，报 Operation not permitted。而 secure_file_priv 控制的是 SQL 层面的文件读写，跟配置文件权限无关，别混淆。

• chattr +i 适合已完全固化配置的离线环境，线上建议慎用；解除需 chattr -i，且只能由 root 执行
• secure_file_priv 是 my.cnf 里的配置项，作用是限制 LOAD DATA INFILE 和 SELECT ... INTO OUTFILE 的路径，和文件系统权限无关
• 真正关键的加固点是：属主/属组 + 权限数字 + 全路径覆盖检查——三者缺一不可