DBeaver中DROP TABLE执行后“没效果”是因为默认关闭auto-commit，语句仅标记待删除，需手动Commit或启用自动提交才生效；事务回滚则表恢复。
默认不设防，删表操作没有二次确认，必须手动加防护。
为什么 DROP TABLE 在 DBeaver 里能直接执行成功却没效果？
这不是“没效果”，而是事务没提交——DBeaver 默认关闭 auto-commit。执行 DROP TABLE 后，表只是被标记为待删除，直到你手动点击 Commit 或启用自动提交才真正落地。很多用户误以为“执行完了=删了”，结果关掉窗口或重启 DBeaver，事务回滚，表完好无损。
- PostgreSQL、Oracle、SQL Server 等严格事务型数据库都遵循此行为
- MySQL 的 InnoDB 引擎同样受事务控制；MyISAM 则不支持事务，
DROP会立即生效（但无法回滚） - 你在 DBeaver 的 SQL 编辑器里点“执行”只运行语句，不等于“提交”
如何开启自动提交防止漏提交？
这是最直接的防护手段，适合开发/测试环境，避免因忘记提交导致误判。
- 菜单栏 → 窗口（Window） → 首选项（Preferences）
- 左侧导航：连接（Connection） → 连接类型（Connection Type）
- 勾选
默认自动提交（Auto-commit） - 点击
Apply，再点OK
⚠️ 注意：该设置对**已存在的连接不生效**，需重新建立连接，或在已有连接上右键 → “编辑连接” → “初始化”标签页里勾选“启用自动提交”。
有没有更严格的删表拦截机制？
没有内置“禁止 DROP”的开关，但可通过组合策略降低风险：
- 用低权限账号连接：给日常账户只授
SELECT、INSERT、UPDATE，不给DROP、TRUNCATE权限（MySQL 中可REVOKE DROP ON database.* FROM 'user'@'host';） - 禁用高危语句自动补全：首选项 → 编辑器 → SQL 编辑器 → 代码完成 → 取消勾选
Enable DROP/CREATE statements completion - 习惯性加事务包装：写
BEGIN; DROP TABLE t1; COMMIT;而非裸写DROP，强制自己看到事务边界 - 生产环境绝对不用 root 或 DBA 账号直连 DBeaver；所有变更走审批+SQL 工单系统
删错表后还能抢救吗？
能，但高度依赖数据库自身机制，和 DBeaver 无关：
- Oracle：查
user_recyclebin，用FLASHBACK TABLE ... TO BEFORE DROP恢复（前提是没加PURGE） - PostgreSQL：无回收站，只能靠备份或 WAL 归档做时间点恢复（
pg_restore或recovery_target_time） - MySQL：InnoDB 无原生回收站，
DROP后只能从最近备份 + binlog 回放（前提是你开了binlog_format=ROW且保留足够长）
别指望 DBeaver 提供“撤回上一条语句”功能——它不是 IDE，不记录语句历史快照。删表保护，终究是权限、流程和习惯的事。
