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）、暂停应用服务（通用）
