怎么快速定位 MySQL 错误日志文件位置
MySQL 错误日志默认开启，但路径不固定——它由
log_error配置项决定，可能在
/var/log/mysqld.log、
/var/log/mysql/error.log或数据目录下（如
/var/lib/mysql/hostname.err）。硬猜容易走错路，最稳的方式是进 MySQL 执行：
SHOW VARIABLES LIKE 'log_error';
返回值就是真实路径。如果返回空或
NULL，说明配置里没显式设置，此时需查配置文件
/etc/my.cnf或
/etc/mysql/my.cnf中是否有
log_error行；若也没有，则按 MySQL 版本和启动方式 fallback 到默认位置（5.7 多为
/var/log/mysqld.log，8.0+ 常在数据目录）。
错误日志里关键信息怎么看
错误日志不是纯文本流水账，每一行都有结构化线索。典型格式如下：
2026-02-04T05:42:13.123456Z 0 [ERROR] [MY-010952] [Server] Too many connections
2026-02-04T05:42:13.123456Z：精确到微秒的时间戳，排查问题时先看“最近几条”是否集中爆发
[ERROR]：严重等级，比
[WARNING]更需立即响应；
[Note]一般可忽略
[MY-010952]：官方错误码，直接搜 MySQL 文档或官网就能定位原因（比如 MY-010952 就是连接数超限）
[Server]：模块来源，常见还有
[InnoDB]、
[Repl]，帮你缩小排查范围 末尾消息：“Too many connections” 是人话提示，但不能只信它——得结合上下文（比如前几行有没有
max_connections相关设置记录）
常见错误日志陷阱与误判点
很多故障看似是 SQL 报错，实则根源藏在错误日志里，但容易被跳过：
服务起不来？别急着重装，先看错误日志第一行——常有Can't start server: can't create PID file（权限/路径不存在）或
InnoDB: Cannot allocate memory for the buffer pool（内存配太大）这类致命提示 主从断开？错误日志里搜
Slave SQL thread retried transaction或
Got fatal error 1236，比 SHOW SLAVE STATUS 更早暴露 binlog 位点异常 慢查询没记录？检查错误日志里有没有
Warning: The log_slow_queries system variable is deprecated—— 说明你用的是旧参数名，实际没生效 日志突然变空？可能是磁盘满（错误日志里会写
Could not write to log file），也可能是
log_error路径所在分区被 mount 为只读
tail -f + grep 实时盯错的实用组合
开发调试或上线观察阶段，别等出事再翻日志。推荐这两个命令组合：
tail -f $(mysql -Nse "SHOW VARIABLES LIKE 'log_error'" | awk '{print $2}') | grep -E "(ERROR|WARNING|MY-|InnoDB)"
解释一下：
$(...)动态取日志路径，
grep -E过滤关键模式，避免刷屏。如果想聚焦某类问题，比如只看 InnoDB 异常：
tail -f $(mysql -Nse "SHOW VARIABLES LIKE 'log_error'" | awk '{print $2}') | grep "InnoDB"
注意：别用
cat xxx.log | grep，错误日志持续追加，
cat会卡死且无法实时更新；
tail -f才是正确姿势。
真正难的不是找到日志，而是把时间戳、错误码、模块名、上下文三行连起来读——比如看到
[InnoDB] Page cleaner took XXXX ms紧接着
[ERROR] InnoDB: Write to file ./ibdata1 failed，基本能断定是磁盘 I/O 或空间问题，而不是 SQL 写错了。
