一、MySQL Binlog 落盘流程

1. 创建 Binlog 缓冲区

• MySQL 启动时会为 每个客户端线程 分配一个线程级（Thread-Level）的 Binlog 缓存，用于临时存储事务中的变更操作。

  • 关键点：

    • 每个线程独立管理自己的 Binlog 缓存（避免并发写入冲突）。

    • 此外，还有一个全局 Binlog 缓冲区（内存队列），用于合并所有线程缓存的数据。

---

2. 变更操作先写入线程级 Binlog 缓存

• 当有数据变更操作（如 INSERT/UPDATE/DELETE）时：

  1. 变更会先写入当前线程的 线程级 Binlog 缓存。

  2. 事务提交时，该线程的 Binlog 缓存会被复制到 全局 Binlog 缓冲区。

  • 关键点：

    • 未提交的事务不会进入全局缓冲区（保证原子性）。

    • 全局缓冲区是所有线程共享的，用于后续批量写入磁盘。

---

3. 将 Binlog 数据写入磁盘

1. 主线程（Main Thread） 负责将全局 Binlog 缓冲区的数据写入磁盘文件。

2. 写入时机由参数 sync_binlog 控制

 二、binlog落盘频率

show global variables like 'sync_binlog';

参数作用

sync_binlog 参数决定了 MySQL 在事务提交时，二进制日志（Binlog）的同步行为。具体来说，它控制 Binlog 数据从内存缓存（binlog cache）写入磁盘的时机。

参数取值及含义

sync_binlog 的取值范围为非负整数，具体含义如下：

• sync_binlog=0：MySQL 不主动同步 Binlog 到磁盘，而是将 Binlog 数据写入文件系统缓冲区，由操作系统决定何时将缓冲区数据刷入磁盘。这种方式性能最高，但数据安全性最低，因为系统崩溃时可能会丢失缓冲区中的 Binlog 数据。

• sync_binlog=1：每次事务提交时，MySQL 都会立即将 Binlog 数据同步到磁盘。这种方式提供了最高的数据安全性，但会增加磁盘 I/O 开销，从而降低性能。

• sync_binlog=N（N > 1）：每提交 N 个事务后，MySQL 将 Binlog 数据同步到磁盘。这种方式在性能和数据安全性之间提供了折中选择。N 的值越大，性能越好，但数据丢失的风险也越高。

配置建议

• 高数据安全性场景：如果对数据安全性要求极高（例如金融系统），建议将 sync_binlog 设置为 1，以确保每次事务提交后 Binlog 数据都被持久化到磁盘。

• 高性能需求场景：如果更注重性能，可以将 sync_binlog 设置为 0 或较大的 N 值，但需注意这会增加数据丢失的风险。