binlog 事件类型是什么
binlog 是一串事件流，而不是一堆 SQL 文本。ROW 格式下，行级变更由 WRITE_ROWS、UPDATE_ROWS、DELETE_ROWS 三类事件承载；DDL 与事务起点由 QUERY 事件承载；XID 标记事务提交；GTID 事件记录事务归属；此外还有 FORMAT_DESCRIPTION、ROTATE、TABLE_MAP 等辅助事件。理解事件类型，才能判断 CDC 工具的输出是否完整、事务边界是否正确。
基本信息
| 前提配置 | binlog_format=ROW 才能提供完整行镜像，CDC 工具普遍依赖 |
|---|---|
| 行事件 | WRITE_ROWS（插入）、UPDATE_ROWS（更新前后镜像）、DELETE_ROWS（删除前镜像） |
| 结构事件 | TABLE_MAP 描述表结构与列映射，行事件依赖它解析 |
| 事务事件 | QUERY（BEGIN、DDL）、XID（提交）、GTID（事务标识） |
| 辅助事件 | FORMAT_DESCRIPTION（文件头）、ROTATE（切换文件）、PREVIOUS_GTIDS（文件起始的 GTID 集合） |
| 行镜像策略 | binlog_row_image 为 FULL 时带全列，MINIMAL 时更新事件只带变更列与主键 |
典型使用场景
- 排查 CDC 输出缺字段：确认 binlog_row_image 是否被改为 MINIMAL
- 理解事务边界：确认订阅到的变更是否已提交，避免下游看到中间态
- 定位断点问题：跨文件切换时核对 ROTATE 与位点记录是否同步更新
- 验证工具正确性：用 SHOW BINLOG EVENTS 与工具输出逐条比对
- 解析 DDL 影响：从 QUERY 事件中获取表结构变更时间点
常见事件速查
| 事件 | 含义 | CDC 视角 |
|---|---|---|
| WRITE_ROWS | 插入行的镜像 | 转换为 insert |
| UPDATE_ROWS | 更新前后的行镜像 | 转换为 update，需要完整行镜像 |
| DELETE_ROWS | 删除前的行镜像 | 转换为 delete，或输出墓碑行 |
| QUERY | DDL、BEGIN 等语句 | 提供表结构变化与事务起点 |
| XID | 事务提交标记 | 按事务提交后再下发，避免中间态 |
| GTID | 事务全局标识 | 用于断点续传与去重 |
| TABLE_MAP | 表与列的结构映射 | 行事件解析的前提，缺失则无法解析 |
| ROTATE | binlog 文件切换 | 跨文件时记录新文件名与位点 |
查看事件流
查看事件流
-- 在实例内查看某个文件的事件序列（会扫描文件，生产谨慎）
SHOW BINLOG EVENTS IN 'mysql-bin.000123' LIMIT 50;
-- 输出列：Log_name、Pos、Event_type、Server_id、End_log_pos、Info离线解析（伪 SQL 形式）
离线解析（伪 SQL 形式）
# -v 显示伪 SQL，-v -v 进一步展开字段类型与元数据
mysqlbinlog -v -v --base64-output=DECODE-ROWS /data/binlog/mysql-bin.000123 | head -40
# 关注：TABLE_MAP 出现后才会有 WRITE_ROWS/UPDATE_ROWS/DELETE_ROWS
# XID 出现表示该事务已提交，可安全对外输出一个典型事务是 BEGIN（QUERY）→ 若干行事件 → XID 提交；消费侧应在提交点之后再对外输出，否则长事务期间下游会反复看到未提交的中间状态。
binlog_row_image 被改成 MINIMAL 后，UPDATE 事件只带变更列与主键，CDC 与下游收到的事件会缺少完整行镜像，此时必须靠主键回查源库才能补齐。