一次诊断事务量突高的原因

一次诊断事务量突高的原因

收到监控短信，说更新和插入阀值报警，于是登陆mysql-moniter上查看，确实如此，如图：

登陆mysql服务器上，通过binlog分析，17:05之前和之后的，看是哪个表更新较大。

[root@XXX-02 logs]# mysqlbinlog --no-defaults --base64-output=decode-rows -v -v mysql-bin.053373 |more
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#120802 16:36:47 server id 4713306  end_log_pos 106     Start: binlog v 4, server v 5.1.43sp1-br38368-enterprise-gpl-pro-log c
reated 120802 16:36:47

然后用这条命令分析，得出写操作频繁的表

[root@XXX-02 logs]# mysqlbinlog --no-defaults --base64-output=decode-rows -v -v mysql-bin.053373 |awk '/###/{if($0~/UPDATE|INSERT|DELETE/)count[$2" "$NF]++}END{for(i in count)print i,"\t",count[i]}' | column -t | sort -k3nr | more
UPDATE  DB.Dynamic                133971
UPDATE  DB.User                   54834
UPDATE  DB.Quota                  24938
UPDATE  DB.OrderHistory           24482
UPDATE  DB.BOSSOperation          19767
UPDATE  DB.SmsCount               18235
UPDATE  DB.Buddy                  10919
INSERT  DB.Buddy_Log              10024

=====================================================================

接着查看17:05之后的binlog日志。

[root@XXX-02 logs]# mysqlbinlog --no-defaults --base64-output=decode-rows -v -v mysql-bin.053375 |more
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#120802 17:10:54 server id 4713306  end_log_pos 106     Start: binlog v 4, server v 5.1.43sp1-br38368-enterprise-gpl-pro-log c
reated 120802 17:10:54
# at 106

然后用这条命令分析，得出写操作频繁的表

[root@XXX-02 logs]# mysqlbinlog --no-defaults --base64-output=decode-rows -v -v mysql-bin.053375 |awk '/###/{if($0~/UPDATE|INSERT|DELETE/)count[$2" "$NF]++}END{for(i in count)print i,"\t",count[i]}' | column -t | sort -k3nr
INSERT  DB.Buddy_Log              194160
INSERT  DB.Buddy                  192587
UPDATE  DB.Dynamic                62767
UPDATE  DB.User                   30103
UPDATE  DB.OrderHistory           12507
UPDATE  DB.Quota                  12318
UPDATE  DB.BOSSOperation          9892

这样比较直观的显示出哪些表更新较多，然后找开发确认问题，是否是业务增长导致。