怎么看 MySQL 错误日志在哪
别猜，直接问 MySQL 自己。登录后执行：
SHOW VARIABLES LIKE 'log_error';返回的
Value就是日志绝对路径，比如
/var/log/mysql/error.log或
/usr/local/mysql/data/hostname.err。如果命令没结果，说明日志可能被禁用（极罕见）或 MySQL 根本没起来——此时去查系统日志
/var/log/messages或
journalctl -u mysqld更靠谱。
配置文件里找也行，但注意：MySQL 8.0+ 会忽略权限过宽的配置文件（比如
/etc/my.cnf权限是
777），日志路径就按默认值走，容易误判。所以优先信
SHOW VARIABLES的输出，而不是配置文件里的
log-error。
怎么实时盯住错误日志不漏关键报错
启动、重启、导入大表、主从切换这些高危操作时，
tail -f是刚需：
sudo tail -f /var/log/mysql/error.log别省这个
sudo——多数生产环境日志属
mysql用户，普通用户读不了。看到新内容滚动出来，立刻能判断操作是否成功。
重点不是“有没有 error”，而是“第一个
[ERROR]出现在哪”。很多后续报错只是连锁反应，比如
InnoDB: Unable to lock ibdata1（错误码
11）才是根源，后面一堆
Can't open table都是它引发的。所以日志要从最新处往前翻，找到那个“破局点”。
常见 ERROR 级别日志怎么快速对应到问题
别逐字翻译，抓三个关键字段：
时间戳+
[ERROR]+
MY-XXXXXX错误码（如
MY-012345）。例如：
2025-12-31T14:22:05.123456Z 0 [ERROR] [MY-010909] [Server] Access denied for user 'root'@'localhost'→ 直接查用户权限，不用管前面有没有
Failed password连续刷屏
2025-12-31T14:25:33.789012Z 0 [ERROR] [MY-012574] [InnoDB] Operating system error number 13 in a file operation→
errno 13= Permission denied，立刻检查
ibdata1、
mysql-bin.*文件属主和目录权限
2025-12-31T14:28:11.345678Z 0 [ERROR] [MY-010119] [Server] Can't start server: Bind on TCP/IP port: Address already in use→ 执行
sudo netstat -tulnp | grep :3306，不是杀进程就是改
my.cnf里的
port
错误码查官方文档比百度快：把
MY-012574粘贴进 dev.mysql.com/doc/refman/8.0/en/server-error-reference.html，秒出原因和修复建议。
为什么调高 log_error_verbosity 后反而更难读
设成
3（
SET GLOBAL log_error_verbosity = 3;）确实能看到更多
[Note]，比如连接建立、查询解析细节，但代价是日志体积暴增，关键
[ERROR]被淹没在千行通知里。生产环境不推荐长期开 3，排查具体问题时临时开，确认完立刻切回
2（默认值，含 error + warning）。
真正有用的是组合技：
sudo tail -f /var/log/mysql/error.log | grep -E '\[ERROR\]|\[Warning\]'这样只留最关键的两层信息，既不过滤掉预警信号，又不会被无关通知干扰。记住：日志是工具，不是小说——你不是来读它的，是来让它交出凶手的。
