直接看
[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或上月归档里——别只盯着最新那个文件。
