MySQL Binlog是Server层二进制日志，记录所有DML/DDL写操作，用于主从复制、PITR恢复、审计追踪及增量同步；推荐ROW格式，需配置log_bin=ON、binlog_format=ROW、sync_binlog=1等参数。
MySQL Binlog 是面试中高频考点，尤其在考察主从复制、数据恢复、高可用架构时几乎必问。核心围绕“是什么、怎么用、怎么配、怎么查”四个维度展开。
Binlog 的作用和适用场景
Binlog 记录所有对数据库执行的写操作（DML 和 DDL），不记录 SELECT 等读操作。它不是 InnoDB 专属日志，而是 MySQL Server 层的日志，所有存储引擎共用。
主要用途包括：
- 主从复制：从库通过拉取并重放主库的 binlog 实现数据同步
- 基于时间点的数据恢复（PITR）：配合全量备份 + binlog 回放，可恢复到任意秒级时间点
- 审计与变更追踪：解析 binlog 可还原谁、何时、改了哪条数据
- 增量同步至数仓或消息队列（如 Canal、Maxwell、Debezium）
Binlog 三种格式的区别
MySQL 提供 STATEMENT、ROW、MIXED 三种 binlog_format，生产环境强烈推荐使用 ROW 格式。
- STATEMENT：记录原始 SQL 语句。优点是日志体积小；缺点是函数（如 NOW()、UUID()）、自增主键、触发器等可能在从库产生不一致，且无法支持某些复杂语句的复制
- ROW：记录每一行数据变更前后的镜像（before_image / after_image）。安全性高、一致性好，支持并行复制和 GTID；缺点是日志体积大，尤其是大批量 UPDATE/DELETE
- MIXED：MySQL 自动选择 STATEMENT 或 ROW 模式，但行为不可控，不建议用于生产
如何查看和解析 Binlog
binlog 是二进制文件，不能直接 cat 查看，需用 mysqlbinlog 工具解析：
- 查看指定 binlog 文件内容：
mysqlbinlog mysql-bin.000001 - 按时间范围过滤：
mysqlbinlog --start-datetime="2026-03-05 10:00:00" --stop-datetime="2026-03-05 12:00:00" mysql-bin.000001 - 按 position 范围解析：
mysqlbinlog --start-position=1234 --stop-position=5678 mysql-bin.000001 - 解析 ROW 格式时加
-v或-vv参数可显示行变更详情（如列名、旧值、新值）
Binlog 相关关键参数
这些配置直接影响 binlog 的行为和可靠性：
- log_bin：是否开启 binlog（必须为 ON 才能启用复制）
- binlog_format：设置为 ROW（推荐）
- sync_binlog：控制 binlog 写入磁盘频率。设为 1 表示每次事务提交都刷盘，最安全但有性能开销；设为 0 表示依赖 OS 刷盘，风险高
- expire_logs_days 或 binlog_expire_logs_seconds：自动清理过期 binlog，避免磁盘占满
- server_id：每个 MySQL 实例必须配置唯一 server_id，主从复制依赖此标识识别节点身份
