必须用--base64-output=decode-rows -v参数组合才能解析row格式binlog真实变更，否则仅显示伪sql占位符；-vv可补充字段类型，gtid或xid事件是准确定位事务的唯一可靠锚点。
直接用 mysqlbinlog 解析 ROW 格式 binlog 是唯一可靠方式，STATEMENT 或 MIXED 格式在复杂事务中极易丢失上下文或产生歧义。
必须用 --base64-output=DECODE-ROWS -v 才能看清真实变更
ROW 格式 binlog 默认输出是 base64 编码的 blob，不加参数根本看不到字段值。只用 -v 会显示伪 SQL（如 ### UPDATE `db`.`t1`），但没数据；加 --base64-output=DECODE-ROWS 才能还原出 @1=123 这类实际值。
- 漏掉
--base64-output=DECODE-ROWS：输出全是### INSERT INTO `test`.`user`这种空壳，无法判断哪行被改了 - 只用
-v不用-vv：看不到字段类型（比如/* DATETIME(0) */），遇到 NULL 或时区问题容易误判 - 生产环境建议固定用
mysqlbinlog --base64-output=DECODE-ROWS -vv，避免因参数缺失漏关键信息
定位复杂事务得靠 GTID 或 Xid_log_event 而不是时间/位点
一个大事务可能跨多个 binlog 文件、持续几十秒，用 --start-datetime 容易截断开头或结尾；用 --start-position 更危险——事务起始位点不在文件头，人工找极易错位。
- 优先查
SHOW BINLOG EVENTS IN 'mysql-bin.000005' LIMIT 20，找Anonymous_Gtid或Xid类型事件，记下end_log_pos - 用
mysqlbinlog --include-gtids='f8a1e9c2-1a2b-11ef-8a0d-00163e000001:12345'精确提取整个 GTID 事务 - 若无 GTID，用
mysqlbinlog --base64-output=DECODE-ROWS -vv mysql-bin.000005 | grep -A 5 -B 5 'Xid'定位 Xid 事件前后范围
解析结果里 ### SET 和 ### WHERE 的顺序决定操作类型
ROW 格式不记录原始 SQL，而是靠字段标记推断动作：### WHERE 存在 + ### SET 存在 = UPDATE；只有 ### SET = INSERT；只有 ### WHERE = DELETE。但复杂事务里可能混着多条，必须逐段看。
- UPDATE 场景下，
### WHERE是变更前快照，### SET是变更后值——误删数据时，### WHERE里的条件就是你该恢复的依据 - 遇到
### INSERT INTO后紧接### DELETE FROM，大概率是 REPLACE 或 ON DUPLICATE KEY UPDATE，不能简单当成两条独立语句 -
### @1=NULL表示该字段为 NULL，/* nullable=1 is_null=1 */是元信息，二者必须同时出现才确认为空值，否则可能是默认值
真正难的不是解析命令，而是把分散在多个事件里的同一事务拼全——GTID 是唯一可信锚点，没开启 GTID 的老实例，只能靠 Xid + 时间窗口 + 人工核对 end_log_pos 连续性，这里出错一丁点，恢复就全盘错乱。
