binlog文件损坏或缺失会导致恢复失败，必须验证完整性与连续性：用mysqlbinlog --verify-binlog-checksum校验crc32（需mysql 5.6.3+且binlog_checksum=crc32），ls -1 mysql-bin.* | sort -v检查编号连续性，mysqlbinlog -v抽样解析头尾事件，并交叉比对事务边界。
binlog 文件损坏或缺失会导致恢复失败，必须在恢复前验证其完整性与连续性，不能只靠文件存在就认为可用。
用 mysqlbinlog --verify-binlog-checksum 检查单个 binlog 是否校验通过
该命令直接读取 event 尾部的 CRC32 校验值，并与重新计算的值比对。仅当 MySQL 启用了 binlog_checksum = CRC32（默认开启）时才有效。
- 运行
mysqlbinlog --verify-binlog-checksum mysql-bin.000012，若无输出即通过；若报错Failed to verify checksum，说明该文件已损坏 - 不支持管道或重定向后校验（如
| head会截断 event，导致误报） - MySQL 5.6.3+ 才支持此参数，低于该版本需依赖
md5sum或跳过校验（风险高） - 注意：即使校验通过，也不能保证逻辑完整（比如事务未写完、被强制截断）
用 ls -1 mysql-bin.* | sort -V 确认 binlog 编号是否连续
编号中断意味着日志丢失，常见于磁盘满、FLUSH LOGS 失败、或手动删除了中间文件。
- 执行
ls -1 mysql-bin.* | sort -V，观察输出是否为严格递增序列（如mysql-bin.000001→mysql-bin.000002→ …） - 若发现跳号（如缺
.000005），则无法做时间点恢复（PITR），只能恢复到上一个完整 binlog 的末尾 - 检查
mysql-bin.index文件内容是否与磁盘文件一致，避免索引残留已删文件名
用 mysqlbinlog --base64-output=DECODE-ROWS -v 抽样解析头尾事件
校验通过 + 编号连续，仍不能确保每个 event 都可解析——某些损坏可能绕过 checksum（如 header 被覆盖但 checksum 字段未变）。
- 运行
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000012 | head -n 20，确认开头有# at 4、FORMAT_DESCRIPTION_EVENT和有效server id - 再运行
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000012 | tail -n 20，检查结尾是否有XID_EVENT或STOP_EVENT，而非突然中断或乱码 - 若
head报错Could not read file或解析出大量Unknown event type，说明文件头部已损，不可用 - ROW 格式下务必加
--base64-output=DECODE-ROWS，否则-v无法显示真实变更数据
真正容易被忽略的是：checksum 只校验单个 event，不校验事务边界。一个事务跨多个 binlog 文件时（如大事务写入中途 rotate），必须人工确认 PREVIOUS_GTIDS_EVENT 和 XID_EVENT 的衔接是否正常——这需要结合 SHOW MASTER STATUS 和相邻文件的解析结果交叉比对。
