只有row格式的binlog才能准确还原变更细节并生成可靠回滚sql；statement或mixed模式因缺失行镜像，无法保证回滚准确性，需通过show variables like 'binlog_format'确认并设为row，且确保binlog_row_image=full。
确认 Binlog 格式是否支持行模式
只有 ROW 格式的 Binlog 才能准确还原出原始 SQL 的变更细节；STATEMENT 或 MIXED 模式下，日志只记录语句本身，无法可靠生成回滚语句。执行 SHOW VARIABLES LIKE 'binlog_format'; 查看当前值，如果不是 ROW，回滚操作大概率会失败或产生误判。
常见错误现象：用 mysqlbinlog 解析后发现只有 UPDATE t SET x=1 这类语句，没有前镜像（before image）和后镜像（after image），说明日志不是行格式，此时不能用于生成回滚 SQL。
- 生产环境建议始终使用
ROW模式，且开启binlog_row_image = FULL（默认值，但需确认） -
binlog_row_image = MINIMAL会导致 UPDATE 日志缺失未修改字段，回滚时可能丢失关键条件 - MySQL 5.6+ 默认为
ROW，但升级或迁移后容易被忽略重置
用 mysqlbinlog 提取指定时间段/位置的变更事件
先定位误操作发生的时间范围或 binlog 文件 + position，再用 mysqlbinlog 导出为可读文本。关键参数必须带 --base64-output=DECODE-ROWS -v，否则看不到行数据变化。
示例命令：
mysqlbinlog --base64-output=DECODE-ROWS -v --start-datetime="2024-06-10 14:20:00" --stop-datetime="2024-06-10 14:25:00" /var/lib/mysql/mysql-bin.000012
- 务必加
-v（verbose），否则只显示 event header，不输出 row change detail -
--database=xxx可过滤库，但注意它只过滤USE xxx切换后的事件，不能完全替代表级过滤 - 如果误操作跨多个 binlog 文件，需按顺序拼接解析结果，避免漏掉事务中间的 commit
识别 INSERT/UPDATE/DELETE 并反向构造 SQL
Binlog 中每个 DML 都对应明确的 event type：Write_rows_v1（INSERT）、Update_rows_v1（UPDATE）、Delete_rows_v1（DELETE）。回滚逻辑不是简单把 INSERT 改成 DELETE，而是依赖镜像数据：
- 对
INSERT：回滚是DELETE WHERE pk = ?，需从Write_rows的 “rows” 部分提取主键或唯一键值 - 对
DELETE：回滚是INSERT，需从Delete_rows的 “rows before images” 还原整行数据 - 对
UPDATE：回滚是UPDATE SET col=val WHERE pk = ?，用 “before image” 的主键 + “before image” 的所有列值
注意：如果表无主键，Delete_rows 和 Update_rows 会以全字段作为 WHERE 条件，生成的回滚 SQL 可能误匹配其他行——这是最危险的场景，务必提前验证。
执行前必须人工核对并限制作用范围
自动生成的回滚 SQL 永远不能直接在生产库跑。哪怕工具声称“100% 精确”，也必须做三件事：
- 把生成的 SQL 导出到文件，用
grep检查 WHERE 条件是否都含主键或足够唯一性约束 - 在测试库执行前，先用
SELECT模拟 WHERE 条件，确认命中的行数与预期一致 - 加上
LIMIT 1或临时加AND 1=0测试语法，尤其注意字符串中的单引号、反斜杠是否被正确转义
最容易被忽略的是事务边界：Binlog 中一个事务可能包含多个表操作，而回滚工具常按表拆分输出。如果误删了 A 表又更新了 B 表，只回滚 A 表的 DELETE 而忽略 B 表的 UPDATE，状态仍不一致。
