MySQL误删数据可恢复的前提是binlog已开启且格式为ROW；需用mysqlbinlog定位误删前的position，生成反向INSERT语句回滚，并验证数据一致性。
确认 binlog 是否开启且格式正确
MySQL 误删数据后能恢复的前提，是 binlog 必须处于开启状态，且格式为 ROW（而非 STATEMENT 或 MIXED）。STATEMENT 格式下，DELETE 语句只记录 SQL 文本，无法还原具体哪几行被删；ROW 格式则会记录每一行的前镜像（before image），才能精准回滚。
- 检查是否启用：
SHOW VARIABLES LIKE 'log_bin';—— 返回ON才行 - 确认格式：
SHOW VARIABLES LIKE 'binlog_format';—— 必须是ROW - 查 binlog 文件列表：
SHOW BINARY LOGS;，注意最近一次刷盘时间是否覆盖误删操作 - 如果没开 binlog，或格式不是
ROW，这条路基本走不通，得从备份或从从库拉数据
定位误删操作所在的 binlog 位置和事件
不能靠猜，得用 mysqlbinlog 解析并筛选出目标 DELETE 语句发生的时间点、文件名和偏移量（position）。关键不是“找到 DELETE”，而是“找到它之前最近的 GTID 或 server_id+end_log_pos，作为恢复起点”。
- 先按时间粗筛：
mysqlbinlog --base64-output=DECODE-ROWS -v --start-datetime="2024-05-20 14:30:00" --stop-datetime="2024-05-20 14:35:00" /var/lib/mysql/mysql-bin.000012 - 在输出中找
### DELETE FROM `db`.`table`及其前面的# at XXXXX—— 这个XXXXX就是该事件起始 position - 重点看
### SET @1=... @2=...行，确认删的是哪些主键值；如果用了WHERE id IN (1,2,3)，这里会逐行列出每行的旧值 - 别直接用
--stop-position停在 DELETE 事件末尾——得停在它前一个事件的end_log_pos，否则就又删了一次
生成反向 SQL 并安全执行回滚
MySQL 官方不提供“自动回滚”功能，mysqlbinlog 输出的是原始事件，需要人工转换成 INSERT 或 REPLACE 语句。最稳妥的做法是：解析出被删行的完整字段值，拼成 INSERT，再导入。
- 用
--base64-output=DECODE-ROWS -v解析后，复制所有### INSERT INTO ... VALUES形式的反向语句（注意：这是工具解析出来的伪 SQL，不是真实执行的） - 实际执行前，务必加
WHERE条件或临时表验证：INSERT INTO table_bak SELECT * FROM table WHERE id IN (1,2,3); - 禁止直接在原表上跑
INSERT ... SELECT回填——万一主键冲突或触发器副作用，可能引发二次错误 - 如果表有自增主键且已插入新数据，回填时要显式指定主键值，避免自增错位
恢复后必须验证数据一致性
回滚操作本身不报错，不代表数据对了。特别是大表、高并发场景下，binlog 中可能夹杂其他事务的中间状态，仅靠 position 截断容易漏掉关联变更。
- 比对行数只是第一步，更要核对关键字段（如
updated_at、状态字段）是否与误删前一致 - 如果有唯一索引或业务逻辑依赖时间戳，检查是否存在重复或时间倒挂
- 如果误删发生在主从架构中，且从库还没同步完，优先从从库
SELECT ... INTO OUTFILE拉数据，比解析 binlog 更快更准 - 线上环境切忌边恢复边写入——至少临时
FLUSH TABLES WITH READ LOCK，或确保应用层已切断写流量
真正难的不是命令怎么敲，是判断哪一段 binlog 属于“干净的、可逆的、无交叉影响”的窗口。这个边界往往藏在 GTID 集合交集、事务拆分点、甚至半同步复制的 ACK 状态里——日常就得把 binlog_row_image = FULL 和定期校验 binlog 可读性当成运维基线。
