不能回滚。已提交的UPDATE无法用ROLLBACK撤销；仅当事务未提交且autocommit=OFF时，可用Ctrl+Shift+R或ROLLBACK;回退；若已提交，须依赖binlog（需ROW格式且未过期）或备份恢复。
DBeaver 本身不保存历史快照，也不能直接“撤销”已提交的 UPDATE/DELETE —— 能否回退，完全取决于你是否提前开启了事务，或数据库是否启用了 binlog 并保留了足够日志。
执行 UPDATE 后立刻发现错了，还没 COMMIT
这是最理想的情况：修改还在当前事务里，没真正写入磁盘。
- 在 DBeaver 中按
Ctrl+Shift+R（Windows/Linux）或Cmd+Shift+R（macOS），触发ROLLBACK - 或者手动执行 SQL：
ROLLBACK;，注意末尾分号不能少 - 确认当前连接右下角状态栏显示 “
Transaction active” 才有效；如果显示 “Auto-commit on”，说明每次执行都自动提交，ROLLBACK就不起作用
已经 COMMIT 了，但 MySQL 开了 binlog 且日志没过期
这是生产环境最常用的补救路径，但必须满足两个硬条件：MySQL 配置中启用了 log_bin，且误操作时间点仍在 binlog 保留窗口内（比如只保留 7 天，而误删是 10 天前的，就无效）。
- 先确认 binlog 是否启用：
SHOW VARIABLES LIKE 'log_bin';，返回ON才能继续 - 用命令行工具
mysqlbinlog解析日志，定位到误操作前的位置（例如--stop-position=123456）或时间（--stop-datetime='2026-11-03 14:22:00'） - DBeaver 无法直接读取或解析 binlog 文件，它没有内置
mysqlbinlog功能；你得在终端里执行导出，再把生成的 SQL 导入 DBeaver 执行 - 注意
binlog_format必须是ROW，且binlog_row_image = FULL，否则反向生成 UPDATE 的旧值可能缺失
没开 binlog，也没备份，但表结构简单、数据量小
这种情况下没有通用回滚机制，只能靠人工“猜”或从残留信息中重建。
- 检查是否有其他环境（如测试库、开发库）存在近期一致的数据副本
- 查应用日志：如果业务系统记录了修改前后的完整 payload，可从中提取原始值
- 看 DBeaver 的 SQL 编辑器历史（
Ctrl+Shift+H），有时能翻到刚执行过的 SELECT 查询结果，可复制粘贴重建 - 不要尝试用
SELECT ... FROM information_schema或performance_schema恢复已删数据 —— 这些视图不存用户数据快照
为什么 DBeaver 的“恢复数据库”功能帮不上忙
菜单里的 工具 → 恢复数据库 只是导入一个完整的 .sql 备份文件，相当于全量覆盖。它不是“回滚单条语句”，也不做增量还原。
- 如果你只有误操作前 24 小时的全量备份，恢复后会丢失这 24 小时所有正常变更
- 该功能依赖你提前用
mysqldump或 DBeaver 自己的导出数据功能生成过备份，且备份时间早于误操作时刻 - 执行前务必新建空库，避免覆盖当前库中仍有效的数据
真正关键的不是“怎么在 DBeaver 里点几下”，而是日常是否设置了 autocommit=OFF 习惯、是否定期验证 binlog 有效性、是否对高危操作强制要求双人复核 —— 这些细节，比任何回滚技巧都管用。
