必须确保 binlog 开启且格式为 ROW，否则无法精确恢复；需用 mysqlbinlog 加 --base64-output=DECODE-ROWS -v 解析 DeleteRowsEvent 并转为 INSERT，推荐用 pymysqlreplication 库避免手动拼接错误。
确认 binlog 是否开启且格式为 ROW
没开 binlog 或格式是 STATEMENT，基本没法精确恢复。先连上 MySQL 执行：SHOW VARIABLES LIKE 'log_bin'; 和 SHOW VARIABLES LIKE 'binlog_format';。两个结果都必须是 ON 和 ROW。如果 log_bin 是 OFF，说明日志根本没记录，后续所有操作都无效；如果 binlog_format 是 STATEMENT，DELETE 只记语句本身，不存被删的行数据，无法还原具体内容。
定位误删操作在 binlog 中的位置
关键不是找 “DELETE” 字样，而是找对应表的 DeleteRowsEvent 记录。用 mysqlbinlog 解析目标 binlog 文件时，必须加 --base64-output=DECODE-ROWS -v 参数，否则看不到实际行数据。常见错误是漏掉 -v 或写错路径导致解析失败。
- 先查当前活跃 binlog：
SHOW BINARY LOGS; - 再按时间范围缩小搜索：
mysqlbinlog --start-datetime='2026-08-10 14:00:00' --stop-datetime='2026-08-10 14:30:00' --base64-output=DECODE-ROWS -v /var/lib/mysql/mysql-bin.000042 | grep -A20 -B5 'DELETE FROM your_table_name' - 真正要抓的是
### DELETE FROM开头、后面跟着多行### @1=...的块 —— 那才是被删的原始数据
把 DeleteRowsEvent 转成 INSERT 语句执行
手动拼 SQL 极易出错：字段顺序错、NULL 处理漏、字符串未转义、时间戳格式不对。最稳妥的方式是用 Python + pymysqlreplication 库直接解析事件流，生成带占位符的 INSERT 语句。别信网上那些用 sed 简单替换的“一行命令”，它对含逗号、单引号、JSON 字段的记录会直接崩。
- 确保
server_id和连接参数匹配生产库配置 -
only_events=[DeleteRowsEvent]必须显式指定，避免混入其他事件 - 生成的
INSERT要检查是否包含SET NAMES utf8mb4，否则中文可能乱码 - 执行前先导出到文件验证：
python parse.py > restore.sql，再用mysql -u root -p db_name
恢复后必须验证主键和唯一约束是否冲突
被删的数据重新插入时，如果原表有自增主键且已分配过更大值，直接 INSERT 可能触发 Duplicate entry 错误。不要盲目加 IGNORE 或删主键重插 —— 这会掩盖真实问题。
- 先查当前最大自增值：
SELECT AUTO_INCREMENT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='your_db' AND TABLE_NAME='your_table'; - 对比恢复数据里的
id值，若存在大于该值的记录，需临时ALTER TABLE ... AUTO_INCREMENT = N - 唯一索引冲突更隐蔽，建议恢复后跑一次
SELECT COUNT(*) FROM your_table GROUP BY unique_col HAVING COUNT(*) > 1
恢复成败往往卡在 binlog 保留时长和事件解析精度上。很多 DBA 看到 mysqlbinlog 输出就以为找到了，其实没注意到 @1= 后面的值是否完整、是否有 NULL 标记、时间字段是否被自动转换成本地时区 —— 这些细节不核对，插进去的数据就是错的。
