Binlog
Binlog 是 MySQL 对外记录数据库变更事实的二进制日志，主要服务于复制、时间点恢复和下游变更消费。
#type / concept
#status / growing
#tech / dev / backend
#resource / database
#resource / mysql
[!info] related notes
Binlog
一句话定义
Binlog 是 MySQL 记录数据库变更事件的二进制日志，重点服务于复制、时间点恢复和下游消费，而不是 InnoDB 内部页恢复。
它要解决什么问题
即使数据库自己已经能靠内部日志做崩溃恢复，系统仍然常常还需要回答：
- 其他实例怎么知道主库发生了什么变更
- 想恢复到某个时间点，变更顺序从哪里拿
- 下游同步程序如何持续消费数据库里的变化
Binlog 就是在回答这些“对外传播变更事实”的问题。
核心机制 / 工作原理
1. Binlog 关注的是“发生了什么变更”
它的重点不是某个页如何恢复，而是：
- 哪个语句或哪次事务做了什么变更
- 这些变更按什么顺序发生
- 下游如何按顺序继续处理
所以 Binlog 更像数据库对外输出的一条变更事实流。
2. Binlog 的典型用途不是本地页恢复
它的常见用途包括：
- 主从复制
- 基于时间点的恢复
- 某些变更订阅或数据同步链路
这决定了 Binlog 的视角和 Redo Log 很不一样。
3. Binlog 让数据库变化可以被“继续消费”
一旦主库写入了 Binlog：
- 从库可以按顺序复制
- 同步程序可以把事件送到别的系统
- 运维可以基于变更序列做回放和恢复
所以 Binlog 在很多架构里不只是恢复工具，也是一条集成接口。
最小例子 / 最小场景
主库上的订单插入、状态更新和删除等操作被写入 Binlog，从库或同步程序再按顺序消费这些事件，把变更复制到其他实例或下游系统。
这里最重要的不是“某个页怎么改”，而是“这次事务产生了哪些对外可传播的变更事实”。
从原理上最该抓住什么
1. Binlog 和 Redo Log 解决的问题不同
- Redo Log 关心存储引擎如何在崩溃后把已提交修改重做出来
- Binlog 关心数据库如何把变更事实对外传播、复制和回放
它们都重要，但不在一个层面。
2. Binlog 更接近“数据库外部视角的变化序列”
所以它常被下游系统关注，而不只是被数据库内核自己消费。
3. 理解 MySQL 日志时，先分层再谈细节
一个很稳的分法是：
先把层次分清，后续术语就不容易混。