先用 mysqlbinlog --no-defaults 解析日志确认损坏，报错如 found invalid event 即存在损坏，但需排除版本不匹配；可用 --force-read、--start-position 等跳过损坏点；检查 sync_binlog=1、binlog_format=ROW、磁盘空间及系统日志；无备份时可试 binlog2sql 或十六进制手动修复。
确认损坏是否真实存在
先别急着修复，用 mysqlbinlog --no-defaults 命令尝试解析日志，比如：mysqlbinlog --no-defaults /var/lib/mysql/mysql-bin.000012
如果报错类似 found invalid event in binary log 或 could not read entry at offset XXX，说明确实损坏。但要注意：部分报错可能是因版本不匹配（如用 MySQL 5.7 的 mysqlbinlog 解析 MySQL 8.0 的 binlog），建议使用与服务端同版本的客户端工具。
跳过损坏位置继续解析
若只需恢复损坏点之后的有效数据，可用以下参数绕过错误位置：
- --force-read：强制读取，跳过无法识别的事件
- --offset=N：从指定偏移量开始读（需结合 hexdump -C 或日志报错中的 offset 估算）
- --start-position=N：从某个已知有效的 event 起始位置开始（如上一个成功解析的 end_log_pos + 1）
例如：mysqlbinlog --force-read --start-position=124 /var/lib/mysql/mysql-bin.000012 > good_part.sql
检查 binlog 配置与文件完整性
损坏常源于配置或写入异常，重点核查：
- sync_binlog 是否为 1（非 0 或其他值），避免断电/崩溃导致日志未刷盘
- binlog_format 是否为 ROW（STATEMENT 格式下部分操作不可逆，且更易因 SQL 重放失败被误判损坏）
- 磁盘空间是否充足，满盘会导致 binlog 写入截断
- 查看系统日志（dmesg | tail、/var/log/messages）是否有 I/O 错误或 ext4 journal 报错
没有备份时的补救尝试
若 binlog 是唯一恢复依据，且关键事务在损坏前，可考虑：
- 使用 binlog2sql（支持跳过错误并提取 DML）：python binlog2sql.py -h127.0.0.1 -P3306 -uuser -p'pwd' -dtest -tuser_info --start-file='mysql-bin.000012' --start-pos=4 --stop-pos=120
- 对于严重损坏文件，用十六进制编辑器（如 xxd）人工定位 EVENT_HEADER（固定 19 字节头），比对正常 binlog 结构，手动截断无效尾部
- 若是主从环境，检查从库 relay log 是否完整——有时主库 binlog 损坏，但从库已成功中继并落盘
