共计 1552 个字符，预计需要花费 4 分钟才能阅读完成。
作者：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 是二进制文件，所以无奈间接应用文本关上，须要应用对应的解析工具才能够查看具体内容。
2.1 show binlog events
show binlog events 形式能够解析指定 binlog 日志，但不合适提取大量日志，速度很慢，不倡议应用。
2.2 mysqlbinlog
mysqlbinlog 是 mysql 原生自带的 binlog 解析工具，速度快而且能够配合管道命令过滤数据，适宜解析大量 binlog 文件，倡议应用。
因为 windows 上面无奈应用管道命令如此简洁的提取出 SQL，所以这边就只写 Linux 下的应用办法。我平时的做法会将 windows 上面的 binlog 拷贝到 Linux 下，再利用 Linux 的管道命令解析。
集体罕用的 Linux 下解析命令：mysqlbinlog /data/mysql_data/bin.000008 –database EpointFrame –base64-output=decode-rows -vv –skip-gtids=true |grep -C 1 -i “delete from Audit_Orga_Specialtype” > /opt/sql.log
- /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，不同的只是日志的记录形式和解析办法：
