查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测试写入） - Windows 下默认日志名是
hostname.err，而 hostname 可能含空格或点号，导致路径解析异常
实时监控与快速过滤：别用 cat 硬啃全量日志
错误刚发生时，tail -f 是最有效的观察手段，尤其适合重启、导入、DDL 操作等场景：
tail -f /var/log/mysql/error.log
配合 grep 快速定位高频问题：
- 查连接拒绝：
grep -i "access denied" /var/log/mysql/error.log - 查 InnoDB 崩溃迹象：
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，基本可锁定外键约束问题 -
崩溃前最后几秒：MySQL 异常退出时，日志末尾常有
[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 或上月归档里——别只盯着最新那个文件。
