mysql启动失败提示“can’t open Error log file”主因是mysqld用户对log_error路径无读写权限，需检查目录所有权、selinux上下文及logrotate配置，并注意初始化时log_error被忽略。
MySQL 启动失败时提示 Can't open error log file
这通常不是日志文件本身被删了，而是 MySQL 进程（通常是 mysqld 用户）对日志路径没有读写权限。常见于手动迁移数据目录、重装后改路径、或用 root 初始化再切回普通用户运行的场景。
检查方法：
sudo -u mysql touch /var/log/mysql/error.log 2>/dev/null || echo "权限不足"如果报错，说明 mysql 用户连创建空文件都做不到。
- 确认日志路径：查
my.cnf中的log_error配置项，注意它可能在[mysqld]或[server]段下 - 路径必须存在且可写：MySQL 不会自动创建父目录，
/var/log/mysql/目录本身也要有mysql:mysql所有者和755权限 - SELinux 可能拦截：centos/RHEL 上执行
ls -Z /var/log/mysql/，若上下文不是mysqld_log_t，需用semanage fcontext -a -t mysqld_log_t "/var/log/mysql(/.*)?"+restorecon -Rv /var/log/mysql
log_error_verbosity 设为 3 却看不到连接拒绝类错误
MySQL 8.0+ 的 log_error_verbosity 控制错误日志详细程度，但默认不记录客户端连接被拒绝的完整原因（比如因 skip-networking 或绑定地址限制），这类信息只出现在启动时的 stderr 输出或 systemd journal 中。
- 要捕获连接类拒绝，得配合
general_log = ON（仅调试用，性能开销大）或检查systemctl status mysqld -
log_error_verbosity = 3主要影响内部崩溃、复制线程异常、InnoDB 启动失败等事件的堆栈深度，不扩展网络层日志 - 若日志里反复出现
access denied for user却没来源 IP，说明客户端根本没走到认证阶段——大概率是防火墙、bind-address配置或skip-networking导致的连接中断
日志轮转后 mysqld 写不进新文件
Linux 下常用 logrotate 管理 MySQL 错误日志，但默认配置常漏掉关键一步：通知 MySQL 重新打开日志文件。轮转后旧文件被重命名，新文件由 logrotate 创建，但 mysqld 进程仍持有旧文件描述符，导致日志“消失”。
- 必须在
logrotate配置中加入postrotate … mysqladmin flush-logs … endscript，触发 MySQL 自行重建日志句柄 - 避免用
copytruncate：它靠截断原文件实现，但 MySQL 对已打开的文件截断后可能写入位置错乱，引发日志损坏 - 验证是否生效：轮转后执行
mysql -e "SHOW VARIABLES LIKE 'log_error';"，再对比lsof -p $(pgrep mysqld) | grep log显示的文件路径是否更新
自定义日志路径时 mysqld --initialize 不认 log_error
初始化实例时（如首次部署），mysqld --initialize 会忽略 my.cnf 中的 log_error 设置，强行写到数据目录下的 hostname.err。这不是 bug，是设计行为——初始化阶段配置加载机制不同。
- 初始化完成后，必须手动把生成的
.err文件移到目标路径，并确保my.cnf中log_error指向它，再重启服务 - 不能靠软链接绕过：MySQL 会检测符号链接并拒绝启动，报错
Log error file is a symbolic link - 如果想跳过初始化日志，可用
--log-error=命令行参数覆盖，例如：mysqld --initialize --user=mysql --datadir=/var/lib/mysql --log-error=/var/log/mysql/init.log
权限问题最麻烦的不是找不到错误，而是错误藏在别的地方——比如 systemd 的 journalctl -u mysqld 里有 “Permission denied” 提示，但 error.log 根本没生成，因为连日志文件都打不开。