MySQL 中的 binlog（Binary Log） 的 写入方式、作用与功能、以及底层原理 - 指南
1. 什么是 binlog
binlog是 MySQL 的二进制日志记录，记录了所有对数据库造成更改的操作（如 INSERT、UPDATE、DELETE），但不记录 SELECT 等只读操作。
它是 MySQL主从复制、数据恢复、审计的核心基础。
2. binlog 的写入方式
MySQL 的 binlog 写入方式由参数sync_binlog 控制：
sync_binlog 值 | 写入方式 | 特点 |
|---|---|---|
| 0 | 事务提交时，binlog 写入 OS 缓冲区，不立即刷盘 | 性能高，但可能丢失数据 |
| 1 | 每次事务提交时，binlog 写入并立即刷盘 | 最安全，但性能稍低 |
| N>1 | 每 N 次事务提交后才刷盘 | 性能与安全折中 |
写入流程：
- 事务执行过程中，生成 binlog 事件（Event）。
- 事务提交时，将事件写入binlog cache。
- 根据
sync_binlog配置，决定是否立即刷盘到磁盘文件。 - 刷盘完成后，事务才算真正提交成功。
3. binlog 的作用与作用
- 主从复制
主库将 binlog 发送给从库，从库按顺序执行，保持数据一致。 - 数据恢复
结合mysqlbinlog工具，可以将 binlog 转换为 SQL 语句，恢复误删数据。 - 审计与追踪
记录所有数据变更，方便追踪问题。 - 增量备份
只备份 binlog 文件，可快速恢复到某个时间点。
4. binlog 的底层原理
4.1 存储结构
binlog 文件由多个Event组成，每个 Event 记录一次材料变更。常见 Event 类型：
- Query Event：记录执行的 SQL 语句。
- Row Event：记录行级变更（基于
binlog_format=ROW）。 - Xid Event：记录事务提交标识。
4.2 写入机制
- MySQL 在事务执行时，会先将变更记录到binlog cache（每个线程独立）。
- 事务提交时，将 cache 中的内容写入 binlog 文件。
- binlog 文件是追加写入，不会覆盖旧数据。
- binlog 文件达到
max_binlog_size时，会自动切换到新的文件。
4.3 三种 binlog 格式
| 格式 | 特点 | 优缺点 |
|---|---|---|
| STATEMENT | 记录 SQL 语句 | 日志小，但可能因环境差异导致复制不一致 |
| ROW | 记录行数据变更 | 复制最准确，但日志大 |
| MIXED | 自动选择 STATEMENT 或 ROW | 兼顾准确性与大小 |
5. binlog 与事务的关系
MySQL 的事务提交过程（InnoDB 引擎）：
- 写入 redo log（保证事务持久性）。
- 写入 binlog（保证复制与恢复）。
- 两者都写入成功后，事务才算提交（两阶段提交机制）。
这种 两阶段提交保证了 binlog 与数据的一致性，避免主从复制出错。
✅ 总结：
- MySQL 数据复制与恢复的核心就是binlog 。
- 写入方式由
sync_binlog控制，影响性能与安全性。 - 底层通过 binlog cache + 追加写入实现，并配合两阶段提交保证一致性。
补充：
statement模式下，每一条会修改素材的sql都会记录在binlog中。不得记录每一行的变化，减少了binlog日志量，节约了IO，提高性能。由于sql的执行是有上下文的，因此在保存的时候需要保存相关的信息，同时还有一些使用了函数之类的语句无法被记录复制。
row级别下通过，不记录sql语句上下文相关信息，仅保存哪条记录被修改。记录单元为每一行的改动，基本是能够全部记下来但是由于很多操作，会导致大量行的改动(比如altertable)，因此这种模式的文件保存的信息太多，日志量太大。
mixed，一种折中的方案，普通操作使用statement记录，当无法运用statement的时候运用row。
逐行记录。就是此外，新版的MySQL中对row级别也做了一些优化，当表结构发生变化的时候，会记录语句而不