MySQL错误日志路径可通过SHOW VARIABLES LIKE 'log_error'直接查得，优先于配置文件；实时监控用sudo tail -f配合grep过滤ERROR/Warning，聚焦首个MY-XXXXXX错误码定位根因。
怎么看 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\]'这样只留最关键的两层信息，既不过滤掉预警信号，又不会被无关通知干扰。记住：日志是工具，不是小说——你不是来读它的，是来让它交出凶手的。
