最准方法是登录MySQL后执行SHOW VARIABLES LIKE 'log_error';，返回Value值即真实路径，如/var/log/mysqld.log；若服务未启动，则查配置文件my.cnf/my.ini中[mysqld]段的log_error配置，未配置时默认在datadir目录下以hostname.err命名。
直接查 log_error 变量最准
MySQL 启动失败、连不上、报错没头绪？先看错误日志，而它的路径不是靠猜或记默认值，是靠查——登录 MySQL 后执行：SHOW VARIABLES LIKE 'log_error';
返回的 Value 字段就是真实路径，比如 /var/log/mysqld.log 或 /var/lib/mysql/hostname.err。这个值优先级最高，覆盖配置文件、安装方式、系统习惯所有干扰项。
- 必须能登录 MySQL 才能执行；如果服务根本起不来，这条就失效，得换方法
- 注意大小写：
log_error不是log-error（后者是配置文件写法） - 返回为空或
NULL？说明 MySQL 没启用错误日志（极罕见），或配置有严重语法错误导致变量未加载
查不到 MySQL？翻配置文件 my.cnf 或 my.ini
服务挂了、mysql 命令进不去，就别硬试了。错误日志路径通常明写在配置里，只是位置分散：
- Linux 常见路径：
/etc/my.cnf、/etc/mysql/my.cnf、/usr/local/mysql/etc/my.cnf，或/etc/mysql/conf.d/*.cnf里的某个文件 - Windows 一般在：
C:\ProgramData\MySQL\MySQL Server X.X\my.ini（ProgramData是隐藏目录） - 找到
[mysqld]段，搜log_error =这一行；没这行，就按“默认规则”推断
配置文件可能被多个位置同时加载，优先级：用户级 ~/.my.cnf > 系统级 /etc/my.cnf > 实例级指定文件（如启动时加 --defaults-file）。用 mysqld --help --verbose | grep "Default options" 可看到实际加载顺序。
配置里没写 log_error？那就去 datadir 下找 hostname.err
MySQL 的“兜底逻辑”很明确：只要没显式配置 log_error，它就把错误日志写进数据目录（datadir）下，文件名是主机名加 .err 后缀。所以两步走：
- 先查数据目录：
SHOW VARIABLES LIKE 'datadir';→ 得到类似/var/lib/mysql/ - 再进该目录看文件：
ls -lh /var/lib/mysql/*.err，通常就是your-hostname.err
常见坑：
• macOS Homebrew 安装默认 datadir 是 /usr/local/var/mysql/，日志就是 /usr/local/var/mysql/$(hostname).err
• Docker 容器里，datadir 往往映射到宿主机某路径，得进容器查或看 docker inspect 输出
• Linux 下若用 systemd 启动，有时会强制重定向日志到 journal，此时 log_error 虽设了，但实际内容在 journalctl -u mysqld 里
日志文件权限不对，tail 报 Permission denied 怎么办
查到路径了，cat 或 tail -f 却打不开？不是路径错，是权限卡住了。MySQL 进程以 mysql 用户身份运行，日志文件属主通常是 mysql:mysql，普通用户无权读。
- 安全做法：用
sudo tail -n 50 /var/log/mysqld.log（只读，不改权限） - 别手欠
chmod 644 *.err—— 日志文件被其他用户可写，可能被注入伪造记录 - 更稳妥的是切到
mysql用户查：sudo -u mysql tail -n 50 /var/log/mysqld.log - 如果日志路径在
/var/lib/mysql/下，更要小心：那里整个目录权限本就严格，乱改可能影响 mysqld 启动
真正容易被忽略的是：日志路径本身存在，但父目录不可执行（no execute 权限），ls 都列不出来。这时连 sudo 都救不了，得先 sudo chmod +x 父目录（仅临时排查用）。
