技术分享MySQLbinlog日志解析

　　作者：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，不同的只是日志的记录方式和解析方法：
　　推荐：
　　社区近期动态