如何定位 MySQL 错误日志文件路径
MySQL 启动失败或运行异常时，第一件事不是猜原因，而是确认错误日志在哪——因为默认位置因安装方式差异极大，
mysqld可能根本没写入你预设的路径。 通过
SHOW VARIABLES LIKE 'log_error';查看当前生效路径（需有
SELECT权限且 MySQL 正常运行） 若 MySQL 无法启动，直接查配置文件：
/etc/my.cnf、
/etc/mysql/my.cnf或
/usr/etc/my.cnf，搜索
log_error行；未显式配置时，Linux 下默认常为
/var/log/mysqld.log或
/var/log/mysql/error.log，macOS Homebrew 安装则多在
/usr/local/var/mysql/*.err注意：如果配置了
log_error = syslog，日志会走系统日志，此时应查
journalctl -u mysqld（systemd）或
tail -f /var/log/messages
用 grep / awk 快速提取关键错误模式
原始错误日志通常混杂启动信息、慢查询、连接日志（取决于配置），人工翻找效率低。真正有用的线索集中在特定关键词行，不建议全文打开。
查崩溃相关：grep -i "crash\|signal\|segfault\|Fatal" /var/log/mysqld.log查启动失败原因：
grep -A 5 -B 5 "mysqld: Shutdown complete\|Aborting" /var/log/mysqld.log（关注异常终止前后的上下文） 查权限/路径问题：
grep -i "permission denied\|cannot open\|failed to create" /var/log/mysqld.log查 InnoDB 恢复异常：
awk '/InnoDB: Starting crash recovery/,/InnoDB: End of log/' /var/log/mysqld.log（这段区间若卡住或报 checksum error，基本可判定数据页损坏）
mysqladmin debug 输出的内存与锁状态怎么看
mysqladmin debug不输出到错误日志，而是触发
mysqld将内部状态 dump 到错误日志末尾，是排查死锁、连接堆积、内存泄漏的轻量级手段，但很多人 dump 完就不管了。 执行后立即
tail -n 200 /var/log/mysqld.log，重点看三块：
Thread pointers（活跃线程数是否异常高）、
Event Scheduler:（事件调度器是否卡死）、
LOCK WAIT（若有，说明存在未释放的行锁或表锁） 若看到大量
Waiting for table metadata lock，大概率是长事务或 DDL 操作阻塞了其他查询，需结合
SELECT * FROM information_schema.INNODB_TRX;查事务持有时间 注意：该命令需要
PROCESS权限，且频繁执行会影响性能，单次诊断够用，别加 cron
pt-query-digest 能分析错误日志吗？不能，但可以补位
pt-query-digest是 Percona Toolkit 的核心工具，但它解析的是
slow query log或通用查询日志，**对错误日志无效**。不过当错误由慢查询引发（如超时导致连接中断、锁等待超时），它能帮你定位源头。 先确认开启了慢日志：
SELECT @@slow_query_log, @@long_query_time;，再用
pt-query-digest /var/log/mysql/slow.log找出平均响应 >2s 的语句 常见误用：把错误日志路径传给 pt-query-digest，结果报
unrecognized file format—— 它只认 SQL 文本格式，不认 MySQL 错误行前缀（如
2024-05-10T08:22:11.123456Z 12345 [ERROR]） 替代方案：用
awk '$3 ~ /\[ERROR\]/ {print}' /var/log/mysqld.log | sort | uniq -c | sort -nr 统计错误类型频次，比盲目翻日志更高效
错误日志本身不记录 SQL 内容（除非是明确的语法错误提示），真正要关联 SQL 和错误，得靠 general log + 错误时间戳对齐，或者上链路追踪工具。别指望一个日志文件包打天下。
