用 SHOW VARIABLES LIKE 'log_error' 可直接获取MySQL错误日志绝对路径，若返回空则日志未启用；否则需检查路径权限、SELinux策略、logrotate配置及修改后是否重启服务。
直接查路径：用 SHOW VARIABLES LIKE 'log_error' 最准
登录 MySQL 后执行这条命令，返回的 Value 就是当前正在写入的错误日志绝对路径——这是唯一不依赖系统权限、不猜默认值、不翻配置文件的可靠方式。如果返回空或 NULL，说明错误日志根本没启用，不是“找不到”，而是“没开”。
- 常见返回值：
/var/log/mysqld.log（CentOS）、/var/log/mysql/error.log（Ubuntu）、/usr/local/mysql/data/localhost.err（源码安装） - Windows 下可能返回类似
C:\ProgramData\MySQL\MySQL Server 8.0\Data\DESKTOP-ABC.err，注意ProgramData是隐藏目录，资源管理器需开启“显示隐藏的项目” - 若返回路径不存在或无法读取，别急着改日志位置——先检查 MySQL 是否真在运行：
systemctl status mysqld或ps aux | grep mysqld
路径查不到？去配置文件里翻 log_error 配置项
当 MySQL 连不上、或者 SHOW VARIABLES 报错时，只能靠配置文件定位。重点不是“找 my.cnf”，而是确认它是否被真正加载、且写在对的段落里。
- Linux 常见位置：
/etc/my.cnf、/etc/mysql/my.cnf、/usr/etc/my.cnf；Docker 容器内通常挂载在/etc/my.cnf或/etc/mysql/my.cnf - 必须在
[mysqld]段落下找log_error = /path/to/error.log——写在[client]或[mysql]段完全无效 - 如果整个文件没这行，MySQL 会退回到默认行为：把日志写进数据目录（
datadir）下，文件名通常是主机名加.err，比如/var/lib/mysql/myserver.err
日志文件打不开？权限和 SELinux 是最大拦路虎
即使路径正确、文件存在，tail -f /var/log/mysql/error.log 报 “Permission denied”，大概率不是你少输 sudo，而是权限链断了。
- 日志父目录必须由
mysql用户可写：sudo chown -R mysql:mysql /var/log/mysql，不能只改日志文件本身 - SELinux（RHEL/CentOS）常静默拦截写入：临时验证用
sudo setenforce 0，若日志立刻出现，说明是 SELinux 策略问题，需恢复后用sudo semanage fcontext -a -t mysqld_log_t "/var/log/mysql(/.*)?"修复上下文 - 日志轮转后生成
error.log.1或error.log-20260125.gz？用zcat或gunzip -c解压查看，别直接cat二进制压缩包
历史日志怎么看？MySQL 不自动归档，全靠 logrotate
MySQL 自己从不重命名、压缩或删除旧错误日志。所谓“历史日志”，99% 是系统级日志轮转工具（如 logrotate）干的活——没有配置，就只有当前那个 error.log 文件。
- 检查是否有轮转痕迹：
ls -lt /var/log/mysql/error.log*，看到error.log.1、error.log.2.gz就说明已配置 - 关键配置项在
/etc/logrotate.d/mysql-server中：rotate 7表示保留 7 份、compress表示压缩、postrotate ... flush-logs是让 MySQL 切到新日志文件的关键步骤 - 如果没配，又想留历史记录，别手动复制——直接补 logrotate 配置，否则重启 MySQL 时旧日志可能被覆盖
最常被忽略的一点：修改 log_error 路径后，必须重启 MySQL 才生效，而且新路径的父目录要提前建好、权限设对。很多人改完配置就 tail，发现日志没动静，其实是 MySQL 根本没启动成功——去看系统日志：journalctl -u mysqld -n 50 --no-pager，比死盯错误日志更早发现问题。
