错误日志默认是开的，但路径可能不明确
MySQL 8.0+ 大多数发行版（如官方二进制包、RPM、APT 安装）默认已启用错误日志，但路径往往不直观：可能是
/var/log/mysqld.log、
/var/lib/mysql/hostname.err，甚至输出到
stderr（尤其 systemd 管理时）。你不能靠“没改就一定有日志”来排查问题，必须验证。 登录 MySQL 后执行：
SHOW VARIABLES LIKE 'log_error';—— 如果返回
NULL或空值，说明未启用；如果返回路径（如
/var/log/mysql/error.log），说明已配置；如果返回
stderr，说明日志被重定向到系统日志（
journalctl -u mysqld查看） 默认行为不可靠：某些 Docker 镜像或精简安装会跳过日志配置；MySQL 5.7 以前版本在某些编译选项下甚至不写文件
手动指定 log_error 路径必须满足三个硬条件
在
my.cnf的
[mysqld]段添加
log_error = /var/log/mysql/error.log不等于日志就能写进去——缺一不可：
/var/log/mysql/目录必须存在，且由 MySQL 进程用户（通常是
mysql）拥有写权限：
sudo mkdir -p /var/log/mysql && sudo chown mysql:mysql /var/log/mysql配置项必须在
[mysqld]下，写在
[client]或
[mysql]段完全无效 MySQL 8.0.14+ 支持动态设置：
SET PERSIST log_error = '/var/log/mysql/error.log';，但该操作仍要求路径可写，且重启后才真正生效（PERSIST 仅保证下次启动加载）
systemd 环境下 log_error 可能被忽略
CentOS/RHEL/Fedora 等使用 systemd 的系统，MySQL 服务常通过
StandardError=journal将错误输出直接交给 journald，此时即使配置了
log_error，MySQL 也可能只往 journal 写、不写文件。 检查是否被接管：
sudo systemctl cat mysqld | grep StandardError，若看到
StandardError=journal或
StandardError=inherit，说明日志被重定向 强制走文件：编辑 service 文件（如
/usr/lib/systemd/system/mysqld.service），注释或删除
StandardError=行，再
sudo systemctl daemon-reload && sudo systemctl restart mysqld或者妥协：用
journalctl -u mysqld -f实时跟踪，比翻文件更实时，但无法用
logrotate管理
常见失败现象和快速自检清单
配置完重启，发现日志文件没生成、没内容、或 MySQL 启动失败？别猜，按顺序查这五点：
配置文件是否被正确加载？运行mysqld --verbose --help | grep "Default options"，确认实际读取的
my.cnf路径（如
/etc/my.cnf、
/etc/mysql/my.cnf、
/usr/etc/my.cnf） 目录权限是否真 OK？
sudo -u mysql touch /var/log/mysql/test.txt 2>/dev/null && echo "OK" || echo "Permission denied"SELinux 是否拦截？
sudo ausearch -m avc -ts recent | grep mysqld，若有拒绝记录，临时关 SELinux 测试：
sudo setenforce 0MySQL 是否根本没起来？
sudo systemctl status mysqld看状态，再
sudo journalctl -u mysqld -n 50 --no-pager查启动失败原因（常见于配置语法错误、路径不可写） 日志文件是否被其他进程占着？比如旧进程残留锁，或磁盘满导致
ENOSPC错误（
df -h /var/log看空间）
路径、权限、加载顺序、systemd 干预、SELinux —— 这五个点覆盖了 95% 的错误日志配置失败场景。少验证一个，就可能卡住一小时。
