查看 MySQL 的 binlog 日志，核心是确认日志是否开启、定位当前文件、再选择合适方式读取内容。复制场景下还需关注事件类型、GTID、位点或时间戳等关键信息，便于故障排查与数据一致性分析。
确认 binlog 是否已启用
登录 MySQL 后执行：
SHOW VARIABLES LIKE 'log_bin';—— 返回 ON 表示已开启
SHOW MASTER STATUS;—— 查看当前正在写入的 binlog 文件名和起始位置（
File和
Position）
SHOW BINARY LOGS;—— 列出所有可用的 binlog 文件及大小，确认归档是否正常
用 mysqlbinlog 工具解析日志文件
这是最常用也最灵活的方式，适合复制分析和恢复操作：
基础查看：mysqlbinlog mysql-bin.000003按时间范围过滤：
mysqlbinlog --start-datetime="2025-12-20 09:00:00" --stop-datetime="2025-12-20 10:30:00" mysql-bin.000003按位置范围过滤：
mysqlbinlog --start-position=1234 --stop-position=5678 mysql-bin.000003显示行级变更（尤其 ROW 格式）：
mysqlbinlog -v --base64-output=DECODE-ROWS mysql-bin.000003远程读取主库日志（用于搭建 binlog server）：
mysqlbinlog --read-from-remote-server --host=10.82.30.102 --port=3308 --user=yau --password mysql-bin.000003
在 MySQL 客户端内直接查看事件
适合快速检查少量事件，无需离开数据库环境：
SHOW BINLOG EVENTS;—— 默认查看第一个 binlog 文件的全部事件
SHOW BINLOG EVENTS IN 'mysql-bin.000003';—— 指定文件查看
SHOW BINLOG EVENTS IN 'mysql-bin.000003' FROM 1234 LIMIT 20;—— 从指定位置开始查 20 条，便于定位某次操作
注意：该命令不支持时间过滤，且对大文件响应慢，仅作辅助验证用。
复制场景下的关键分析点
做复制问题诊断时，重点关注以下内容：
GTID 信息：检查Executed_Gtid_Set是否连续，有无跳过或重复；配合
--exclude-gtids可跳过异常事务 事件类型：识别
Query_event（DDL/DML）、
Rotate_event（日志切换）、
Format_desc_event（格式声明）等 表映射与上下文：ROW 格式中需留意
Table_map_event出现位置，否则后续
Write_rows_event会因缺表定义而无法解析 错误标记：查找
error_code非零的事件，或日志中带
# Warning的行，常对应复制中断原因
