row模式下binlog不记录原始sql，仅保存行变更的二进制字段值；show binlog events仅显示事件类型与表/行信息，无sql文本；mysqlbinlog -v可伪还原sql但无法精确对应原语句；如需审计原始sql，应改用statement模式、general_log、审计插件或应用层日志。
Binlog Row模式下根本不会记录原始SQL
MySQL 在 binlog_format=ROW 模式下，不保存原始 SQL 语句，只保存行变更前后的完整字段值（以二进制格式）。所以你无法“验证原始 SQL”——它压根不存在于 binlog 中。这是 Row 模式的根本设计，不是配置或工具能绕过的。
为什么 SHOW BINLOG EVENTS 看不到 SQL？
SHOW BINLOG EVENTS 在 Row 模式下显示的是事件类型（如 Write_rows_v2、Update_rows_v2），内容字段是空的或仅含 table_id 和 rows，没有 sql_text 字段。常见错误是误以为加 IN 'xxx' FROM xxx 就能捞出 SQL，实际只会看到类似：
12345 | mysql-bin.000001 | 289 | Write_rows_v2 | test | t1 | ...
这不是 bug，是预期行为。Row 模式的目标就是解耦 SQL 语义，避免因函数、变量、非确定性操作导致主从不一致。
如何间接还原可能的原始 SQL？
虽然不能 100% 还原（比如 UPDATE t SET x = x + 1 无法区分是 +1 还是直接赋值），但可通过 mysqlbinlog --base64-output=DECODE-ROWS -v 查看行级变更细节：
-
--base64-output=DECODE-ROWS：强制解码 Row 事件为可读格式 -
-v（或--verbose）：显示列名和前后镜像（### UPDATE `test`.`t1`+### WHERE+### SET） - 注意：输出仍是伪 SQL，WHERE 条件基于主键/唯一键推断，不一定对应原 WHERE 子句
- 如果表无主键，
mysqlbinlog会把整行旧值当 WHERE，极易误判
示例片段：
### UPDATE `test`.`t1` ### WHERE ### @1=1 ### @2='old' ### SET ### @1=1 ### @2='new'
这只能说明“某行 ID=1 的 name 从 old 改成 new”，无法确认原语句是 UPDATE t1 SET name='new' WHERE id=1 还是 UPDATE t1 SET name='new' WHERE name='old'。
想真正审计原始 SQL？换模式或加日志
如果业务强依赖原始 SQL 审计（如合规、回滚溯源），Row 模式不适合你：
- 切回
STATEMENT模式：风险高（非确定性函数、时间函数等可能导致主从不一致） - 启用
general_log：记录所有客户端发来的 SQL，但 I/O 开销大，且不记录隐式执行（如触发器、存储过程内部语句） - 用 MySQL 8.0+ 的
audit log plugin或第三方代理（如 ProxySQL、MaxScale）做 SQL 层拦截 - 应用层打日志：最可控，但需改造代码
Row 模式的价值在于数据一致性，不是可读性。指望它提供可审计的 SQL，就像用 JPEG 去还原 PSD 图层——格式本身就不承载那部分信息。
