数据库日志查看

凌晨两点十七分，数据线上订单表突然写入超时。库日我第一反应不是志查看监控面板，而是数据直接打开MySQL的error log——那行“InnoDB: Page cleaner took a long time”跳出来时，心里反而踏实了。库日日志不会撒谎，志查它只是数据把真相摊开在磁盘上，等你愿意低头去看。库日

很多人把日志查看当成排查故障的志查最后一步，这顺序反了。数据日志应该是库日最先翻的抽屉，而不是志查最后撬的保险箱。我见过一个同事，数据花了四十分钟查索引、库日调参数，志查最后发现是binlog没开导致主从不同步——他要是早五分钟看一眼binlog的POS值，早该收工了。

查看日志的门道，第一层是分清“哪些日志值得看”。MySQL有error log、slow query log、general log、binlog，PostgreSQL还有pg_log和pg_stat_statements。别指望一个文件解决所有问题。慢查询日志里全是低效SQL，但如果你要定位锁等待，看它没用，得去information_schema里查innodb_trx。选错日志，等于拿着菜谱修发动机。

第二层是掌握“怎么看”。别用tail -f死盯着屏幕，那是原始人行为。用grep配合时间戳过滤，比如grep "2025-06-18 02:1[0-5]" error.log，把范围缩到五分钟内。更狠一点，直接写个awk脚本把错误码出现的频率统计出来——高频错误码往往就是系统最脆弱的关节。我习惯先看最近一百行，再往回翻，因为很多故障是渐进式的，尾巴上的记录只是压垮骆驼的最后一根稻草。

第三层是“看完之后怎么办”。日志不是用来欣赏的，是用来对照的。拿error log里的时间点去比对应用日志，看看到底是数据库先崩还是应用先超时。有一次发现数据库报“too many connections”，但应用日志里根本没有连接池满的告警——后来才查出来是某个定时任务忘了释放连接，每次跑完留三个僵尸连接，攒了半个月才爆。那次的教训是：日志里的数字要跟代码里的行为对上，对不上就说明有隐藏逻辑。

说个实战细节。看binlog时别用mysqlbinlog直接刷屏，那玩意儿输出量大得能淹没显示器。用mysqlbinlog --base64-output=DECODE-ROWS -v把行事件解码成可读SQL，再配合--start-datetime和--stop-datetime掐头去尾。有次排查误删数据，我就靠这个把凌晨三点十七分到十八分之间所有DELETE语句捞出来，发现是某个接口没做权限校验，参数直接拼进了删除条件。日志里那行SQL写得清清楚楚，就像凶手留在现场的指纹。

日志查看还有一个反直觉的窍门：有时候最没用的日志反而最值钱。比如general log，平时没人开，因为性能损耗大。但真遇到诡异问题时，开着它跑五分钟，所有发往数据库的语句都记录在案，能立刻揪出是谁在半夜发了条全表扫描。代价是磁盘狂涨，但跟业务停摆的损失比，那点空间不算什么。

工具方面，别迷信那些花哨的日志分析平台。命令行加awk加grep，足以解决九成问题。我见过有人用ELK搭了一套日志系统，结果排查问题时还在SSH到服务器上手动翻文件——因为Kibana里查不到数据库原生日志的上下文。轻量级方案往往更可靠，less加/关键字搜索都比GUI工具来得快。

最后说句实在话：日志查看的核心不是技术，是耐心。你得接受大部分时间日志里什么都没发生，然后突然某一行就改变了整个系统的命运。别指望AI替你读日志，至少现在不行——那些智能告警平台报的“数据库异常”，最后还得靠人眼去确认到底是哪条SQL、哪个锁、哪个IO瓶颈。日志是数据库写给人类的信，别辜负了它。