作者：xuty
很多时候，当我们的业务数据产生了不正常的变化，但却无法得知这类操作是在哪里进行，并且如何进行，单单从程序当面排查很费力。那么就需要通过分析数据库日志来得到历史执行 SQL，根据 SQL 执行逻辑来确认代码位置，进而确认是否是 BUG，亦或是误操作等。
一 、binlog 简介
binlog 是 MySQL Server 层记录的二进制日志文件，用于记录 MySQL 的数据更新或者潜在更新（比如 DELETE 语句执行删除而实际并没有符合条件的数据），select 或 show 等不会修改数据的操作则不会记录在 binlog 中。
通常在 binlog_format = ROW 的环境下，我们可以通过 binlog 获取历史的 SQL 执行记录，前提是必须开启 binlog_rows_query_log_events 参数（默认关闭，建议开启），该参数可以通过rows_query_event 事件记录原始的 SQL，如果不开启的话，则只能获取 SQL 对应的行数据。
二、binlog 解析
由于 binlog 是二进制文件，所以无法直接使用文本打开，需要使用对应的解析工具才可以查看具体内容。
show binlog events 方式可以解析指定 binlog 日志，但不适宜提取大量日志，速度很慢，不建议使用。
2.2 mysqlbinlog
mysqlbinlog 是 mysql 原生自带的 binlog 解析工具，速度快而且可以配合管道命令过滤数据，适合解析大量 binlog 文件，建议使用。
/data/mysql_data/bin.000008：需要解析的 binlog 日志。
database：只列出该数据库下的行数据，但无法过滤 Rows_query_event。
base64-output=decode-rows -vv：显示具体 SQL 语句。
skip-gtids=true：忽略 GTID 显示。
grep -C 1 -i “delete from dataex_trigger_record”：通过管道命令筛选出所需 SQL 及执行时间。
/opt/sql.log：将结果导入到日志文件，方便查看。
结果示例：
小贴士：
1. 如果不确定 SQL 格式或是无法筛选到数据，比如因为 delete from 中间冷不丁多一个空格出来，可以使用 grep 多次过滤筛选，比如 grep -C 1 -i “Rows_query” |grep -C 1 -i “Audit_Orga_Specialtype” |grep -C 1 -i “delete” 筛选对应表上的 delete 操作。
2. 触发器执行的 SQL 不会记录在 Rows_query_event 中，只会记录对应的行数据。
3. –database 是无法过滤 Rows_query_event 的，只可以过滤行数据。
三、解析方式对比
对于常见的数据库（SQL Server、Oracle、MySQL）来说，都具有类似相同的日志来记录历史 SQL，不同的只是日志的记录方式和解析方法：
