共计 969 个字符，预计需要花费 3 分钟才能阅读完成。
最近遇到了一个很奇怪的事，某个服务线上环境中有一张表的数据总是莫名其妙的隐没，说来也很奇怪。然而生产环境又不能做调试，于是只好通过翻各种日志来破案，这里将 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`"