mysql binlog查看器默认不显示row格式真实变更数据，因未启用--base64-output=decode-rows和-v参数，导致仅显示事件头和@变量占位符；必须组合使用这两个参数才能解码并展示old_value/new_value等字段级变更细节。
MySQL Binlog 查看器为什么默认不显示 ROW 格式的真实变更数据？
因为 mysqlbinlog 默认以语句（STATEMENT）或混合（MIXED）模式解析，遇到 ROW 格式时只显示事件头和占位符，比如 ### UPDATE ... 后面空着，或者直接报错 Unknown binlog event type 33（对应 WRITE_ROWS_EVENT_V2）。这不是工具坏了，而是没启用 ROW 解析开关。
必须加 --base64-output=DECODE-ROWS -v 才能还原出字段级变更。否则你看到的只是事件类型、表名、时间戳这些元信息，根本看不到 old_value 和 new_value。
如何用 mysqlbinlog 正确解析 ROW 格式的 Binlog 文件？
关键就两个参数组合，缺一不可：
-
--base64-output=DECODE-ROWS：告诉工具把 base64 编码的 row 数据解码成可读字段操作 -
-v（或--verbose）：开启详细模式，输出每行变更的###前缀格式（如### UPDATE `test`.`t1`、### WHERE @1=1、### SET @2='new'） - 如果只加
-v不加--base64-output=DECODE-ROWS，会看到一堆BINLOG '...' ;的乱码 base64 字符串 - 如果 binlog 是远程拉取的（
--read-from-remote-server），还要确保 MySQL 用户有REPLICATION CLIENT和REPLICATION SLAVE权限
解析结果里 @1、@2 这些变量名代表什么？
它们是 MySQL 内部按列顺序编号的“伪变量”，不是真实字段名。比如建表语句是 CREATE TABLE t1 (id INT, name VARCHAR(20), ctime DATETIME)，那么：
-
@1对应id -
@2对应name -
@3对应ctime
注意：这个顺序严格按 SHOW CREATE TABLE 输出的列定义顺序，跟 SELECT * 或 INSERT 语句里的字段顺序无关。如果表结构后期加过列，旧 binlog 里可能没有 @4，但新 binlog 会有——别硬套字段名，先用 DESC t1 确认当前列序。
为什么有时候解析出来的 WHERE 条件和实际 SQL 对不上？
ROW 格式记录的是“变更前后的行镜像”，不是原始 SQL。所以 UPDATE 事件里 WHERE 部分其实是“变更前的主键/唯一键值”，而 SET 是“变更后的整行值”。它不保留原始条件表达式（比如 WHERE status = 'pending' AND created_at ）。
- 如果你看到
### WHERE @1=5但表里id是主键，那说明这次更新是通过WHERE id = 5定位的 - 但如果更新用了非唯一条件（比如
WHERE email = 'a@b.com'），而该 email 不是索引列，Binlog 仍会记录变更前所有匹配行的完整镜像——此时WHERE部分可能为空，或只包含部分字段（取决于 MySQL 版本和优化器行为） - MySQL 8.0.23+ 支持
--skip-gtids和更稳定的 row 解析，老版本（如 5.7）在大事务或含 BLOB 列时容易截断@N变量，建议配合--hexdump辅助验证
真正难的不是解析命令，而是把 @1=@2=... 映射回业务字段，并意识到 Binlog 里根本没有“SQL 文本”这回事——它只存数据快照。
