最近遇到了一个很奇怪的事，某个服务线上环境中有一张表的数据总是莫名其妙的隐没，说来也很奇怪。然而生产环境又不能做调试，于是只好通过翻各种日志来破案，这里将mysql的log_bin日志的查问过程大抵形容一下。
首先阐明一下，binlog是一个记录了mysql所有操作的二进制文件。
首先，确保曾经关上日志记录，执行sql命令：
show variables like 'log_bin%';
如果是ON的话，就阐明开启了日志记录，并且这个日志记录默认是File，这就是就是咱们接下来要找的文件。如果是记录为到表，那就是间接查数据库了。
第一步，找到日志文件地位
个别状况下，日志文件都会在装置目录下的logs中
然而配置文件能够批改日志存储门路，所以咱们间接用sql命令查找：show master status
这个命令会将最新的一个日志文件地址形容进去。
第二步，找到可编译二进制文件的mysqlbinlog可执行文件
在mysql目录下执行shell命令：find ./ -name mysqlbinlog
如果没找到，那就间接用shell命令(应用前确保有权限)：find / -name mysqlbinlog
第三步，再mysql-bin.010001中找到关键字
比方我要在mysql-bin.010001中找到delete操作，那么就能够用shell命令：
./mysqlbinlog -v ../logs/logbin/mysql-bin.010001 | grep -i delete其中 -i 示意疏忽大小写
因为delete操作非常的多，我还想准确到删除某一张表，那我就能够改写命令：
./mysqlbinlog -v ../logs/logbin/mysql-bin.010001 | grep -i 'delete from tableName'我还想找到delete删除操作的前后几行，比方前三行，后十行，那么我的命令就会变成：
./mysqlbinlog -v ../logs/logbin/mysql-bin.010001 | grep -i -A 10 -B 3 'delete from tableName'还有我的查问条件中蕴含特殊字符：
./mysqlbinlog -v ../logs/logbin/mysql-bin.010001 | grep -i -A 10 -B 3 "insert into tableName (`id`"