查MySQL错误日志需先用SHOW VARIABLES LIKE 'log_error'确认真实路径,关注[ERROR]前3~5行上下文,结合tail -f、grep过滤及时间锚点定位根因,并交叉验证系统日志与性能状态。
直接看 [ERROR] 行,但别只盯这一行——它只是“报警灯”,真正的问题往往藏在它前面 3~5 行的上下文里。
很多人花半小时翻遍 /var/log 却漏掉关键一步:MySQL 实际写的不是你猜的那个路径。最可靠的方式是登录 MySQL 执行:
SHOW VARIABLES LIKE 'log_error';
返回的 Value 才是真实路径。常见误区:
my.cnf 里写了 log-error(带短横),但 MySQL 8.0+ 只认 log_error(下划线)——拼错就静默失效mysql 用户无写权限,会导致日志根本无法生成(ls -l 看文件属主,sudo -u mysql touch /path/to/test 测试写入)hostname.err,而 hostname 可能含空格或点号,导致路径解析异常cat 硬啃全量日志错误刚发生时,tail -f 是最有效的观察手段,尤其适合重启、导入、DDL 操作等场景:
tail -f /var/log/mysql/error.log
配合 grep 快速定位高频问题:
grep -i "access denied" /var/log/mysql/error.log
grep -A 3 -B 1 "InnoDB: Assertion failure\|crash\|corruption" /var/log/mysql/error.log
grep -i "can't start server: bind on" /var/log/mysql/error.log
注意:log_error_verbosity 默认为 2(记录 ERROR + WARNING),若需看到更细线索(如初始化阶段的 Note),需设为 3 并重启 —— 但生产环境慎用,日志量会显著增大。
错误日

[Note] mysqld: ready for connections 或 [ERROR] Plugin 'xxx' init function returned error —— 如果这行没出现,说明启动卡在某步ALTER TABLE 后立刻出现 [ERROR] InnoDB: Cannot add or update a child row,基本可锁定外键约束问题[ERROR] mysqld got signal 11 或堆栈(stack trace),此时必须结合 core dump 和 gdb 进一步分析,单看日志不够一个典型陷阱:日志里出现 [Warning] InnoDB: Retry attempts for writing partial data failed,表面是 IO 错误,但根源可能是磁盘满(df -h)、文件系统只读(mount | grep ro)或 SELinux 限制(ausearch -m avc -ts recent)——日志只报现象,不报根因。
很多“错误”其实是结果而非原因。例如日志里反复出现 [ERROR] Too many connections,实际可能是应用层连接泄漏,此时要交叉验证:
SHOW STATUS LIKE 'Threads_connected';,对比 max_connections 阈值mysqldumpslow -s t /var/log/mysql/slow.log | head -10
SELECT * FROM performance_schema.data_lock_waits;(MySQL 8.0+)真正难排查的问题,往往出现在多个日志的交集处:比如错误日志里报 InnoDB: Failing assertion,慢日志里对应时间段有大事务,而系统日志(/var/log/messages)同时出现 Out of memory: Kill process —— 这时就知道该去调内存或优化事务了。
最容易被忽略的一点:日志轮转后旧文件可能还藏着线索。MySQL 不自动压缩或删除旧错误日志,mysqld.err 被 flush-logs 切走后,真正的历史问题可能躺在 mysqld.err.1 或上月归档里——别只盯着最新那个文件。