STATEMENT格式binlog无法精确回滚，因NOW()等非确定性函数重放结果不一致；ROW格式可定位具体行变更，但需人工拼写反向SQL并验证，PITR时间点恢复更可靠。
binlog_format=STATEMENT 时根本没法靠 binlog 精确回滚
MySQL 的 binlog_format 决定了 binlog 记录的是「SQL 语句」还是「行变更数据」。设为 STATEMENT 时，只记 INSERT INTO t VALUES (1, NOW()) 这种原始语句，但 NOW()、UUID()、@var 等非确定性函数在重放时会取当前时间或新值，导致结果不一致——你删掉的可能不是刚插的那几行。
- 误操作后立刻查
SELECT @@binlog_format，确认是不是STATEMENT - 如果是，别指望靠
mysqlbinlog解析出的 SQL 直接反向执行，大概率错位或漏行 - 这种模式下唯一靠谱的补救是：停写 + 从最近一次逻辑备份（如
mysqldump）恢复 + 补回 binlog 中确定性部分
binlog_format=ROW 才能定位到具体被改的行
ROW 格式记录的是每行数据变更前后的完整镜像（before_image 和 after_image），所以你能精确看到哪几条记录被 INSERT/UPDATE/DELETE 了。但注意：它不记录语句本身，也不告诉你 WHERE 条件是怎么写的。
- 用
mysqlbinlog --base64-output=DECODE-ROWS -v解析 binlog，找到对应误操作的### UPDATE ...或### DELETE ...区块 - 每个
###行后面紧跟着### @1=...，这就是字段值；@1对应第一列，按建表顺序排 - UPDATE 会同时出现
WHERE部分（旧值）和SET部分（新值），DELETE 只有WHERE部分（旧值），INSERT 只有SET部分（新值） - 别直接复制
###行去执行——它们不是合法 SQL，只是调试视图
生成可执行的反向 SQL 要手动拼，不能依赖自动工具
没有通用工具能 100% 安全地把 ROW 格式 binlog 自动转成可逆 SQL。比如多主键、NULL 值、BLOB 字段、字符集隐式转换都容易出错。最稳的方式是人工核对后手写。
- 对误
DELETE：提取WHERE部分所有@i=xxx，拼成INSERT INTO tbl VALUES (xxx, ...)，注意 NULL 要写成NULL，字符串要加引号 - 对误
UPDATE：用WHERE部分（旧值）匹配原记录，用SET部分（新值）反推旧值——即把 SET 当 WHERE，WHERE 当 SET，再写成 UPDATE - 执行前务必在测试库验证：先
SELECT确认目标行是否存在、是否唯一，再START TRANSACTION测试更新效果 - 如果表有自增主键、触发器、外键约束，反向 SQL 很可能失败，得临时关掉
FOREIGN_KEY_CHECKS或调整插入顺序
时间点恢复（PITR）比单条回滚更常用也更可靠
真正在生产环境处理误导入，通常不是一行行“撤销”，而是切到误操作前一秒，整体回档。这要求你有完整的 binlog 归档 + 定期全量备份。
- 用
mysqlbinlog --stop-datetime="2024-05-20 14:23:59"截取到出事前的日志，再导入 - 关键点在于找准
--start-position和--stop-position：先用mysqlbinlog -v扫一遍，记下误操作事件的end_log_pos，上一个事件的end_log_pos就是安全截止点 - 如果 binlog 被轮转过，得确认
SHOW BINARY LOGS列出的文件都在归档路径里，缺一个就断档 - 恢复后立刻校验：对比关键表的
COUNT(*)、MIN(id)/MAX(id)、某几个已知记录的字段值
实际操作中最容易被忽略的，是 binlog 的 expire_logs_days 设置和磁盘空间监控——很多“找不到 binlog”的情况，其实是它被自动清理了。
