1. Binlog 基础：MySQL Binlog 概念、格式与应用场景

各位同学，咱们这门课叫《Binlog多源合并与数据路由》，说白了就是跟 MySQL 的 Binlog 打交道。第一章，我先把地基打牢——Binlog 到底是什么，它长什么样，能干什么。

我记得刚入行那会儿，有个老前辈跟我说：“搞 MySQL 不懂 Binlog，就像开车不看仪表盘。” 当时我不太理解，直到有一次线上数据被误删，全靠 Binlog 才把数据捞回来。嗯，从那以后，我再也不敢小看它了。

1.1 什么是 Binlog？

Binlog，全称 Binary Log，二进制日志。它记录的是 MySQL 数据库所有数据变更操作——INSERT、UPDATE、DELETE，还有表结构变更（DDL）。

你想想看，MySQL 把每一次“谁、在什么时候、改了哪条数据”都记下来，存成一个二进制文件。这就是 Binlog。

它跟 Redo Log 不一样。Redo Log 是 InnoDB 存储引擎自己用的，为了崩溃恢复。Binlog 是 MySQL Server 层的，为了复制和恢复。我习惯把 Redo Log 比作“草稿本”，Binlog 是“正式账本”。

1.2 Binlog 的三种格式

Binlog 有三种格式：STATEMENT、ROW、MIXED。我一个个说，顺便讲讲我在项目里踩过的坑。

1.2.1 STATEMENT 格式

这种格式记录的是 SQL 语句本身。比如你执行了 UPDATE users SET age=age+1 WHERE id=1，Binlog 里就原样记下这条 SQL。

• 优点： 日志量小，一条 SQL 可能只占几十字节。
• 缺点： 依赖上下文环境。比如用了 NOW()、UUID() 这种非确定性函数，主从执行结果可能不一样。

1.2.2 ROW 格式

这种格式记录的是每一行数据变更前后的具体值。比如你更新了一行，Binlog 里会记下“更新前是什么值，更新后是什么值”。

• 优点： 精确，主从一致，不受函数影响。
• 缺点： 日志量大。批量更新 10 万行，ROW 格式会记 10 万条变更记录。

我个人习惯，生产环境一律用 ROW 格式。虽然日志量大一点，但心里踏实。你想想看，数据同步最怕什么？最怕对不上账。

1.2.3 MIXED 格式

MySQL 自己判断：如果 SQL 是确定性的，就用 STATEMENT 记；如果是不确定的，自动切换成 ROW。

听起来挺智能对吧？但我建议你别用。为什么？因为判断逻辑是黑盒，你根本不知道它什么时候切。我曾经排查过一个诡异的主从延迟问题，最后发现是 MIXED 格式下，一条大事务前半段用 STATEMENT，后半段切成了 ROW，导致从库解析混乱。

格式	记录内容	日志大小	主从一致性	我的推荐
STATEMENT	SQL 语句	小	低（依赖上下文）	不推荐
ROW	行变更前后值	大	高（一致）	强烈推荐
MIXED	自动切换	中等	中等（不可控）	不推荐

1.3 Binlog 的应用场景

Binlog 能干的事太多了。我挑三个最常用的说说。

1.3.1 主从复制

这是 Binlog 最经典的应用。主库写 Binlog，从库拉过来回放，实现数据同步。咱们这门课后面讲的多源合并，本质上就是“多个主库的 Binlog 拉到同一个地方”。

1.3.2 数据恢复

误删数据怎么办？用 Binlog 回放。我记得有一次凌晨两点，运维手抖执行了 DROP TABLE，我爬起来用 Binlog 把数据恢复到误删前一刻，全程花了 15 分钟。老板后来给我加了鸡腿。

1.3.3 数据变更捕获（CDC）

这是咱们课程的核心。把 Binlog 实时解析出来，推送到消息队列、搜索引擎、缓存、数仓…… 说白了，就是让 Binlog 成为数据流动的“血管”。

1.4 Binlog 核心结构图

下面这张图，我画了 Binlog 从产生到消费的完整链路。你仔细看看，后面所有章节都围绕这张图展开。

从图上你能看到：应用程序发 SQL 给 MySQL，MySQL 交给 InnoDB 执行，同时把变更写入 Binlog。Binlog 可以被从库拉走做复制，也可以被 Canal、Debezium 这些工具解析，推送到下游系统。

咱们这门课，就是围绕“如何把多个 MySQL 的 Binlog 合并到一起，再按规则路由到不同目标”展开的。第一章先把概念理清，后面咱们再一步步深入。