Linux数据库日志分析核心是定位问题源头、识别异常模式、验证操作行为，需分清日志类型、明确目标、按需选方法，结合多源时间线交叉验证并建立自动化归档与告警机制。
Linux 系统中数据库日志分析的核心是定位问题源头、识别异常模式、验证操作行为。关键不在于堆砌工具，而在于理清日志类型、明确分析目标、按需选取方法。
分清日志来源与类型
不同数据库日志结构差异大，必须先确认日志归属：
- MySQL：关注 error log（启动/崩溃/权限错误）、slow query log（执行超时的 SQL）、general log（全量语句，慎开）、binary log（主从同步与恢复）
- PostgreSQL：主要看 postgresql.log（含 ERROR/WARNING/LOG 级别事件），配合 pg_stat_activity 和 pg_stat_statements 视图辅助判断
- MongoDB：mongod.log 默认记录启动、连接、慢操作（>100ms）、复制集状态，可通过 logLevel 调整详细程度
- 通用系统层日志：/var/log/messages 或 journalctl -u mysqld.service 等，用于排查服务启停、资源限制（OOM killer、磁盘满）、SELinux 拒绝等外围问题
快速定位高频问题的命令组合
无需图形界面，终端几条命令就能抓住重点：
- 查最近错误：grep -i "error\|fail\|panic\|oom" /var/log/mysql/error.log | tail -20
- 找慢查询（MySQL）：mysqldumpslow -s t -t 10 /var/log/mysql/mysql-slow.log
- 看实时连接与卡顿（PostgreSQL）：psql -c "SELECT pid, usename, state, now() - backend_start AS uptime, query FROM pg_stat_activity WHERE state = 'active' ORDER BY uptime DESC LIMIT 5;"
- 追踪日志实时增长：tail -f /var/log/mongodb/mongod.log | grep -E "(slow|ERROR|repl)"
- 检查磁盘 I/O 是否拖累日志写入：iostat -x 1 | grep -E "(sda|nvme|dm-)"（重点关注 %util 和 await）
结合时间线与上下文交叉验证
孤立看一条报错容易误判，要拉通多个日志源比对时间戳：
- 在 error log 中发现 “Connection refused” 错误，时间点为 14:22:03 → 立即查 systemctl status mysqld、journalctl --since "2024-04-05 14:20:00" --until "14:25:00"，确认是否进程意外退出
- 应用报“锁等待超时”，在 MySQL 的 error log 找到 Deadlock found… 提示 → 再查 general log 或 Performance Schema 中对应事务的完整 SQL 链路，定位冲突表与索引缺失
- 备份失败后数据库响应变慢 → 对比备份时间段的 iostat 输出 + mysqladmin proc（查看长事务阻塞）+ slow log 中新增的扫描型查询
自动化归档与基础告警建议
人工翻日志只适合临时排障，长期需建立轻量机制：
- 用 logrotate 管理日志轮转，避免占满 /var；配置 copytruncate 防止服务中断
- 用 awk 或 python 脚本每日统计 error log 中 ERROR 出现次数，邮件通知突增（如较前7日均值上升300%）
- 对 slow query log 做定时解析，输出 TOP 10 执行频次高且平均耗时 >1s 的 SQL，供 DBA 审核索引或改写
- 将关键数据库日志接入 rsyslog 并转发至中心日志服务器（如 ELK 或 Loki），便于跨实例聚合搜索
不复杂但容易忽略：日志时间默认常为本地时区，多机环境务必统一 NTP 并确认日志时间戳是否带时区标识，否则时间线对不齐会极大增加排查成本。
