答案：必须用SHOW VARIABLES LIKE 'log_error';查真实路径，因该值动态反映MySQL当前写入日志的绝对路径，不受配置文件是否加载、默认路径猜测或发行版差异影响，是唯一精准可靠的方式。
直接执行 SHOW VARIABLES LIKE 'log_error'; 就能拿到真实路径，这是唯一不依赖经验、不猜默认值、不翻配置文件的可靠方式。
为什么优先用 SHOW VARIABLES LIKE 'log_error';
MySQL 启动后，log_error 变量的值就是它当前正在写入的日志文件绝对路径——哪怕你改过配置、重启过服务、甚至换过数据目录，只要 MySQL 进程活着，这个值就准。它比查 /etc/my.cnf 更可信，因为配置文件可能没被加载，或被多个片段覆盖；也比“去 /var/log/mysql/ 猜”更稳，因为有些发行版根本不用那个路径。
常见错误现象：SHOW VARIABLES LIKE 'log_error'; 返回空（NULL）或空字符串，不是命令错了，而是 MySQL 根本没启用错误日志——此时不是“找不到”，而是“没开”。
使用场景：
- MySQL 能连上但启动异常反复崩溃，需要立刻定位日志位置
- 刚接手一台陌生服务器，不确定日志是否重定向、是否被 journal 替代
- Docker 容器里 MySQL 日志路径被挂载到奇怪位置，
my.cnf里写的路径和实际不符
log_error 返回空时怎么办
说明 MySQL 没显式配置错误日志，它会退回到默认行为：把日志写进 datadir 目录下，文件名是主机名加 .err 后缀（如 myserver.err）。
操作步骤：
- 先执行
SHOW VARIABLES LIKE 'datadir';拿到数据目录路径 - 再进该目录用
ls -lh *.err查看是否存在主机名命名的.err文件 - 若仍无结果，检查是否启用了 systemd journal：运行
sudo journalctl -u mysqld -n 50 --no-pager，看输出里有没有 MySQL 错误信息
注意：log_error 为空 ≠ 配置文件里没写这行，有可能是配置文件没被加载（比如放错段落、文件权限不对），也可能是 MySQL 启动时用了 --defaults-file 指定了另一个配置。
查到路径后读不了日志？重点排查三件事
即使 SHOW VARIABLES LIKE 'log_error'; 返回了路径，tail -f /var/log/mysql/error.log 仍报 Permission denied，大概率不是少输 sudo，而是下面某个环节断了：
- 文件属主不是
mysql用户，或权限不是640或600（如chmod 640 /var/log/mysql/error.log） - SELinux 启用且上下文不对（RHEL/CentOS 常见）：用
sudo ls -Z /var/log/mysql/看是否为mysqld_log_t，不是就用sudo semanage fcontext -a -t mysqld_log_t "/var/log/mysql(/.*)?"修复，再restorecon -Rv /var/log/mysql - 路径所在分区磁盘满或 inode 耗尽，
df -h和df -i都要查
别忘了：MySQL 从不自动压缩或轮转错误日志，如果日志文件大到几十 GB，tail 会卡死，应优先用 tail -n 1000 或 grep -i "error|crash" /path/to/error.log | tail -20 快速抓关键行。
配置文件里改了 log_error 但没生效
最常踩的坑是：改完 my.cnf 里的 log_error = /new/path/error.log，没重启 MySQL 服务，或者重启失败导致配置没加载。
验证方法：
- 确认 MySQL 进程是否真在运行：
systemctl status mysqld或ps aux | grep mysqld - 确认配置文件被加载：
mysqld --help --verbose | grep "Default options"看实际扫描的配置路径 - 确认修改写在
[mysqld]段内，而不是[client]或其他段 - 重启后立刻再执行
SHOW VARIABLES LIKE 'log_error';，看值是否更新
Windows 下还要注意路径分隔符必须用正斜杠 / 或双反斜杠 \，单反斜杠会被 MySQL 解析为转义字符。
