最稳方式是执行 show variables like 'log_error'; 获取真实路径；若为空则查配置文件或按版本默认位置 fallback。
怎么快速定位 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 写错了。
