ROLLBACK仅对未提交事务有效；已提交的DELETE需依赖binlog/WAL/日志备份恢复，核心是日志是否可用及格式正确，工具如binlog2sql需人工校验后执行。

ROLLBACK 只在未提交事务时有效；已提交的 DELETE 无法靠它恢复，必须依赖日志、备份或工具解析。

事务内未提交：立刻 ROLLBACK

这是唯一能“秒回”的场景，但前提是：DELETE 执行后还没 COMMIT，且仍在同一数据库会话中。

• MySQL/PostgreSQL/SQL Server（显式事务）都支持直接执行 ROLLBACK;，数据立即还原
• 注意某些客户端（如 MySQL Workbench、PL/SQL Developer）默认开启自动提交（autocommit=ON），此时 DELETE 执行完就落地，ROLLBACK 无效
• SQL Server 中若没写 BEGIN TRANSACTION，默认每个语句是独立事务，删完即提交，ROLLBACK 不起作用

已提交的 DELETE：看有没有 binlog（MySQL）或 WAL（PostgreSQL）或完整恢复模式（SQL Server）

没有日志，就没有“前镜像”，恢复基本无解。重点不是“怎么恢复”，而是“日志是否可用”。

• MySQL 要求 log_bin=ON 且 binlog_format=ROW；MIXED 或 STATEMENT 格式下，binlog2sql 可能解析不出被删行的完整字段值
• PostgreSQL 必须开启 archive_mode=on 并配置 WAL 归档，否则 crash 后只能恢复到最近一次基础备份
• SQL Server 需为“完整恢复模式”，且有定期事务日志备份；简单恢复模式下日志会被截断，无法时间点恢复
• 检查日志是否还存在：SHOW BINARY LOGS;（MySQL）、pg_archive_status 目录（PG）、RESTORE HEADERONLY FROM DISK（SQL Server）

用 binlog2sql 生成反向 INSERT（MySQL 最常用实操路径）

这不是“一键恢复”，而是一套需人工校验的精准操作链，漏一步就可能写错或冲突。

• 先定位误删时间范围：mysqlbinlog --base64-output=decode-rows -v mysql-bin.000012 | grep -A 10 -B 2 "DELETE FROM `db`.`table`"，找到 timestamp 或 end_log_pos
• 生成回滚语句：python binlog2sql.py -h127.0.0.1 -P3306 -uuser -p'pwd' -dtest -tstudent --start-datetime='2026-07-01 21:15:00' --stop-datetime='2026-07-01 21:18:00' -B，其中 -B 表示输出 INSERT
• 务必加 --only-dml 过滤掉 DDL（如 ALTER TABLE），避免混入非预期语句
• 不要加 --no-primary-key——它会让生成的 INSERT 缺少主键字段，导致重复插入失败或覆盖其他行
• 生成的 SQL 必须先在测试库执行验证：检查字段类型是否匹配、主键是否冲突、是否有触发器干扰

执行恢复前最易被忽略的三件事

很多人卡在最后一步，不是不会用工具，而是跳过了隔离与校验。

• 原表若有 ON DELETE CASCADE 外键，binlog2sql 不会还原关联子表数据，得手动补全
• 自增主键（AUTO_INCREMENT）可能因后续插入已增长，直接 INSERT 会报主键冲突，需临时 SET @auto_increment_offset 或改用 REPLACE INTO
• 应用层可能还在往表里写新数据，恢复前必须停写：SET GLOBAL read_only = ON;（MySQL）、回收 INSERT/UPDATE 权限（PG）、暂停应用服务（通用）