有时候binlog能救你一条命

mysql的binlog大家都不陌生吧！

binlog是记录所有数据库表结构变更（例如CREATE、ALTER TABLE…）以及表数据修改（INSERT、UPDATE、DELETE…）的二进制日志。

binlog不会记录SELECT和SHOW这类操作，因为这类操作对数据本身并没有修改，但你可以通过查询通用日志来查看MySQL执行过的所有语句。

二进制日志包括两类文件：二进制日志索引文件（文件名后缀为.index）用于记录所有的二进制文件，二进制日志文件（文件名后缀为.00000*）记录数据库所有的DDL和DML(除了数据查询语句)语句事件。

今天就给小伙伴们说一说我遇到的两个问题，但是由于有binlog的存在，成功定位bug的事情

No1.突然有一天客户反馈某用户无缘无故自己积分修改错乱，接到bug反馈，肯定是要看代码的逻辑问题，然后仔细检查一番之后并无发现有代码逻辑问题，之后我们就想到了binlog日志定位bug问题。

No2.某用户钱包自己多了钱了（可以把负责这个业务的程序员拖出去祭天了）。查来查去还是没有代码的逻辑问题。binlog又可以帮上你的忙了！

接下来我就给大家阐述一下我们怎么定位bug的：

（1）首先登陆进入mysql（默认root）

mysql -uroot -p密码

之后执行

show variables like 'log_%';确认是否开启bin_log，如果没开启（根据自己的业务判断是否开启）

之后执行

show master logs;

查看所有的binlog日志

之后根据时间区间我们选择性的截取我们想得到的执行sql记录，最后执行：

/www/server/mysql/bin/mysqlbinlog -vv --start-datetime="2020-03-17 15:45:00" --stop-datetime="2020-03-17 19:00:00" --database=xx /www/server/data/mysql-bin.000005 >/root/xx.sql;

我们将binlog日志写入一个xx.sql的文件里面，这样方便我们查看

之后我们通过打开这个sql文件查看对应sql的语句，比如第一个问题，积分的问题，那么我们可以根据用户的id搜索update的语句进行定位，确认都执行了那些sql才导致的错加积分。这样我们就能很快的定位问题了！