MySQL 错误日志是排查绝大多数服务异常的「第一现场」——它不是性能分析工具，而是数据库启动失败、崩溃、权限拒绝、InnoDB 文件锁冲突等致命问题的唯一可靠线索。
错误日志记录什么？哪些信息真有用？
它不记录普通 SQL 执行结果，只聚焦三类关键事件：
启动/关闭过程：比如Shutdown complete或
Starting MySQL Server，用于确认服务是否真正完成初始化； 严重运行时错误：如
[ERROR] [MY-012345] [InnoDB] Unable to lock ibdata1（文件被占用）、
[CRITICAL] Plugin 'mysqlx' init function returned error（插件加载失败）； 警告级问题：如
[Warning] [MY-010909] Forcing close of thread（连接被强制中断），虽不立即宕机，但常是连接池泄漏或超时配置不当的前兆。
注意：
[Note]级别基本可忽略；
[Warning]要查但不紧急；
[ERROR]和
[CRITICAL]必须立刻响应。
怎么快速定位日志文件位置？别猜路径
不同系统默认路径差异大（Linux 多在
/var/log/mysql/error.log，Windows 常为
C:\ProgramData\MySQL\MySQL Server 8.0\Data\HOSTNAME.err），硬记容易出错。直接进 MySQL 查最稳：
mysql -u root -p SHOW VARIABLES LIKE 'log_error';
输出类似：
+---------------+------------------------+ | Variable_name | Value | +---------------+------------------------+ | log_error | /var/log/mysql/error.log | +---------------+------------------------+
如果返回空值或报错，说明日志可能被禁用（极罕见）或配置有误——此时要检查
my.cnf中是否漏写了
log_error行。
实时盯住错误日志，比重启后翻旧文件管用十倍
很多问题（比如主从同步突然断开、连接数瞬间飙高后被 kill）转瞬即逝。用
tail -f挂着看，比事后查历史文件高效得多：
sudo tail -f $(mysql -Nse "SHOW VARIABLES LIKE 'log_error'" | awk '{print $2}')这条命令自动读取
log_error值并实时追踪，避免手动复制粘贴路径出错。注意加
sudo——日志文件权限通常只允许 root 或 mysql 用户读取。
常见坑：
没加sudo→ 权限拒绝，看不到内容； 日志路径含空格或特殊字符 → 命令崩掉，建议先
echo $(mysql -Nse "SHOW VARIABLES LIKE 'log_error'" | awk '{print $2}') 确认路径是否干净；
日志被轮转（如 error.log.1）→
tail -f不会自动切新文件，需配合
logrotate配置或改用
journalctl -u mysql -f（systemd 环境下更可靠）。
看到报错别急着 Google，先看三要素再动手
每条有效错误日志都自带「解题钥匙」，缺一不可：
时间戳：和业务异常时间对齐，确认是否同一事件； 错误级别 + 编码：如[ERROR] [MY-012345]，
MY-开头是官方编码，去 MySQL 官方错误码文档 直接搜，比第三方博客准确； 上下文进程/模块名：比如
[InnoDB]、
[Server]、
[Replication]，决定该查存储引擎配置、网络参数还是 binlog 设置。
例如日志出现：
2025-12-30T14:22:11.876543Z 0 [ERROR] [MY-011087] [Server] Could not open file '/var/lib/mysql/ibdata1' (OS errno 13 - Permission denied)
立刻锁定：是文件权限问题（errno 13），不是磁盘满也不是路径错，执行
sudo chown mysql:mysql /var/lib/mysql/ibdata1就能解决——而不是去调 innodb_buffer_pool_size。
真正卡住人的，往往不是看不懂错误，而是跳过时间戳和模块名，直接按字面意思瞎试。日志里写的每个词，都是 MySQL 主动告诉你的排查方向。
