MySQL启动时log_error路径不存在或父目录缺失，需手动创建完整目录结构（如mkdir -p /opt/mysql/data）、设mysql用户属主（chown -R mysql:mysql）及执行权限（750），并排查SELinux/AppArmor拦截或Docker挂载不当。
log_error 路径不存在或父目录缺失
MySQL 启动时找不到 log_error 指定的文件路径，常见于自定义日志路径（如 /opt/mysql/data/mysql.err 或 /var/lib/logs/log-err.log）未提前创建目录。MySQL 不会自动创建多级目录，只尝试打开已存在的路径。
- 用
grep log_error /etc/my.cnf确认配置值；若没配，则默认使用数据目录下的hostname.err - 执行
mkdir -p /opt/mysql/data（替换为你的实际路径），确保所有父级目录都存在 - 不要只创建文件：
touch /opt/mysql/data/mysql.err无效，MySQL 需要的是可写入的目录
目录权限或属主不对，mysql 用户无法写入
即使目录存在，若属主不是 mysql 用户、或缺少写权限，也会报 Permission denied。尤其在非标准路径（如 /home/mysql/log）部署时极易发生。
- 运行
chown -R mysql:mysql /opt/mysql/data（注意是-R，递归处理子目录和未来生成的文件） - 权限建议设为
750：chmod -R 750 /opt/mysql/data；避免用777，否则可能触发 SELinux 或 AppArmor 拒绝 - 检查父目录（如
/opt/mysql）是否对mysql用户有执行（x）权限——没有x就进不去，更别说写
SELinux 或 AppArmor 拦截了日志写入
在 CentOS/RHEL（SELinux Enforcing）或 Ubuntu（AppArmor）上，即使权限正确，安全模块仍可能阻止 MySQL 写入非标准路径。错误日志里不会明说，但 journalctl -xe 会显示 AVC denied 记录。
- 临时验证：运行
setenforce 0（CentOS/RHEL），再systemctl start mysqld；若成功，说明是 SELinux 问题 - 永久解决：修改 SELinux 策略，或把日志路径改到白名单内（如
/var/log/mysql/），再restorecon -Rv /var/log/mysql - AppArmor 用户需编辑
/etc/apparmor.d/usr.sbin.mysqld，添加对应路径规则（例如/opt/mysql/data/** rwk,），然后sudo systemctl reload apparmor
Docker 容器内日志路径映射失败
Docker 启动 MySQL 报 No such file or directory，本质是容器内路径未就绪。宿主机挂载点存在 ≠ 容器内对应路径可写，尤其当挂载目标是空目录或权限受限时。
- 不要只挂载文件：
-v /host/logs:/var/lib/logs/log-err.log是错的；必须挂载目录：-v /host/logs:/var/lib/logs - 启动前在宿主机执行：
mkdir -p /host/logs && chmod 777 /host/logs（测试阶段可用；生产环境建议用--user 999:999匹配 mysql UID/GID） - 优先使用 MySQL 官方镜像支持的环境变量，如
-e MYSQL_LOG_CONSOLE=true绕过文件日志，排查更干净
MySQL 的日志路径问题从来不是单点故障，而是目录结构、权限、安全策略、容器挂载四层叠加的结果。最容易被忽略的是父目录的执行权限和 SELinux/AppArmor 的隐式拦截——它们不报具体权限错误，只让 Could not open file 反复出现。
