先把当时的情况摆出来。运维执行删除语句时选错了库，几十张表被清空，备份是前一天晚上的，中间一天的增量数据要单独补回来。
原因不止一个，得分开看。执行删除前没有确认库名。另一种情况是操作没有二次确认流程。
另外，增量日志没有单独归档，和业务盘放一起。
上来先确认备份恢复点
mysql -e "show binary logs"恢复全量备份
mysql -u root -p 库名 < /data/bak.sql随后按时间点重放增量
mysqlbinlog --stop-datetime='2026-01-01 10:00:00' /data/mysql-bin.0* | mysql -u root -p剩下的就是核对数据条数
mysql -e "select count(*) from 库名.表名"手上没有现成的复现脚本，就照着线上请求手工拼了一个。
报错是间歇性的，我蹲守了半小时才抓到一次完整现场。
恢复的判定其实很直接。删除前的数据全部恢复，校验行数与业务核对一致，应用读写正常。
容易忽略的是，重放要跳过被误删的语句，用位置或者时间点精确控制；恢复演练比恢复本身更重要，别等出事才第一次用。同一份配置在测试环境跑通，不代表线上没事，两边的默认值经常不一样。