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根本没生成，因为连日志文件都打不开。
