<p>默认情况下mysqlbinlog解析不出可读SQL，因MySQL 5.7+默认binlog_format=ROW，仅记录行变更二进制事件；需加--base64-output=DECODE-ROWS和-v参数才能输出###开头的伪SQL（如### UPDATE），且不可直接执行。</p>
mysqlbinlog 为什么解析不出可读的 SQL 语句
默认情况下，mysqlbinlog 输出的是事件（Event）的原始格式，不是直接可执行的 SQL。尤其在 MySQL 5.7+ 启用 binlog_format=ROW 时，日志记录的是行变更数据，而非原始语句，此时必须加 --base64-output=DECODE-ROWS -v 才能看到反解后的伪 SQL（如 ### UPDATE ... WHERE 形式）。
常见错误现象：mysqlbinlog mysql-bin.000001 输出大量十六进制或 BINLOG '...' 块，没有 INSERT/UPDATE/DELETE 文本。
- 务必确认 binlog 格式：执行
SHOW VARIABLES LIKE 'binlog_format';，ROW模式下必须加-v和--base64-output=DECODE-ROWS -
STATEMENT模式下可省略-v，但仍有部分函数（如NOW()、UUID()）被重写，需注意时间戳不一致问题 - MySQL 8.0 默认启用
binlog_row_image=FULL，能还原完整行镜像；若为MINIMAL或NOBLOB，-v输出中可能缺失某些字段值
如何按指定时间段精确过滤二进制日志
mysqlbinlog 支持基于事件时间（event_time）而非文件系统时间进行范围筛选，关键参数是 --start-datetime 和 --stop-datetime，格式必须为 'YYYY-MM-DD HH:MM:SS'，且受 MySQL 服务端时区影响（不是本地 shell 时区）。
容易踩的坑：--start-datetime='2024-05-20 10:00:00' 可能漏掉 10:00:00.000001 这一刻的事件——因为该参数匹配的是事件的 when 时间戳，精度到秒，毫秒级事件可能被截断。
- 更稳妥的做法是用
--start-position+--stop-position（配合mysqlbinlog --verbose --base64-output=DECODE-ROWS先定位起止 offset） - 跨文件时间段查询需显式列出多个 binlog 文件：
mysqlbinlog --start-datetime='2024-05-20 10:00:00' --stop-datetime='2024-05-20 11:00:00' mysql-bin.000001 mysql-bin.000002 - 如果 MySQL 开启了
log_bin_use_v1_row_events=OFF（MySQL 5.6.3+ 默认），-v解析出的###行才准确；否则旧格式可能导致列偏移错乱
解析结果里怎么快速定位某张表的 DML 操作
mysqlbinlog 不支持内置表名过滤，只能靠外部命令配合。最常用且可靠的方式是先用 -v 解析，再用 grep 筛选 ### UPDATE `db`.`tbl` 这类标记行（注意反引号和空格）。
注意：WHERE 条件中的主键值、更新前后的字段值都出现在 ### 行之后，每行以 ### 开头，格式固定：
### UPDATE `test`.`users` ### WHERE ### @1=1 ### SET ### @2='newname'
- 用
grep -A 3 -B 1 '### UPDATE `mydb`.`mytable`'可连带上下文查看完整变更 - 避免只搜
UPDATE或mytable——可能命中注释、库名、字段名等干扰项 - 如果日志量极大，建议先用
mysqlbinlog --base64-output=DECODE-ROWS -v > decoded.log落盘再处理，避免重复解析开销
解析时报错 “Could not read entry at offset” 或 “Invalid replication event”
这类错误通常意味着你试图解析一个不完整、损坏或被截断的 binlog 文件，或者该文件已被 purge 删除但仍在磁盘残留（例如磁盘满导致写入中断）。
真实场景中，mysqlbinlog 对文件末尾校验极敏感：哪怕最后几个字节损坏，也会报 Invalid replication event 并终止解析。
- 先运行
mysqlbinlog --base64-output=DECODE-ROWS -v --force-read mysql-bin.000001 2>&1 | head -20，加--force-read跳过损坏事件继续输出（适合诊断） - 检查文件是否完整：
mysqlbinlog --no-defaults mysql-bin.000001 | tail -10，正常结尾应有END_LOG_POS和Xid事件 - 若确认文件损坏，不要依赖其恢复数据；优先从备份 + 完整 binlog 链路重建，而不是强行修复单个文件
时间范围解析真正麻烦的地方不在语法，而在于 binlog 文件本身是否连续、未被截断、且事件时间戳未被 NTP 或时钟回拨污染——这些细节一旦出问题，--start-datetime 就会失效或漏数据。
