DBeaver 默认不拦截DROP等写操作，因设计上信任用户输入，生产环境需通过数据库层设read_only或客户端预检来防范误执行。
为什么 DROP 语句在 DBeaver 里容易误执行
因为 DBeaver 默认不拦截 DROP、TRUNCATE、DELETE 这类写操作，只要语法合法、权限足够，按 Ctrl+Enter 就直接发给数据库——而 PostgreSQL/MySQL 等默认也不开启只读模式，事务未提交时你甚至看不到效果，一刷新才发现表真没了。
这不是 DBeaver 的 bug，是它作为通用客户端的设计取向：信任用户输入。但生产环境里，一次手抖光标停错位置，就可能触发整库清空。
用只读连接 + 数据库级 read_only 防住 90% 场景
最可靠的方式不是靠客户端拦截，而是让数据库自己拒绝写操作：
- MySQL 8.0+：连库时在连接 URL 加参数
?serverTimezone=UTC&useSSL=false&allowPublicKeyRetrieval=true，再在数据库侧执行SET GLOBAL read_only = ON;（需super权限），普通账号执行DROP会直接报错ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement - PostgreSQL：连接后执行
SET default_transaction_read_only = on;，或更彻底地，在postgresql.conf中设default_transaction_read_only = on并重启；若想禁止用户临时关闭，用ALTER ROLE your_user SET default_transaction_read_only = on; - DBeaver 连接配置里勾选“只读连接”（Connection → Connection Settings → General → Read-only connection）仅影响 UI 提示和部分自动补全，**不阻止实际执行**，不能替代数据库层设置
客户端侧加一层 SQL 关键词拦截（有限但即时）
DBeaver 本身不提供关键词黑名单功能，但可通过外部手段干预：
- 开发阶段用
jsqlparser写个预检脚本：把 SQL 文件喂给 Java 解析器，遍历 AST 判断是否含DropTable、Truncate节点，有则阻断并输出位置行号——适合 CI 流程或 pre-commit hook - 运维人员可手动在 DBeaver SQL 编辑器中搜索
^\s*(DROP|TRUNCATE|DELETE\s+FROM)\b（正则模式），快速定位高危语句；注意别漏掉带换行或注释的变体，比如TRUNCATE\nTABLE - 禁用快捷键：在 DBeaver 首选项（Window → Preferences → General → Keys）里，把
Ctrl+Enter的绑定从 “Execute SQL Statement” 改成 “No Binding”，强制走鼠标点击或Ctrl+Shift+Enter（选中执行），多一道确认动作
执行前必须检查的三个状态栏信息
哪怕开了 read_only，也别跳过这三处确认：
- 左下角连接状态栏：确认显示的是目标库名，且旁边有绿色小锁图标（表示已认证），不是“无连接”或连到了测试库
- SQL 编辑器右上角：看当前激活的连接名称是否与预期一致，DBeaver 允许多连接共存，但快捷键只作用于当前编辑器绑定的连接
- 执行后立刻切到“结果”面板 → “消息”页签：不要只盯绿色对勾。如果看到
0 rows affected却执行了DROP TABLE，说明事务没提交或连接被设为只读；如果看到ERROR: permission denied或ERROR: cannot drop table because it is being used，至少说明语句被拦住了
真正危险的不是 DROP 本身，是它在你没意识到的情况下成功执行了——而 DBeaver 不会弹窗问“确定要删表吗？”，它只负责把你的键盘输入原样转发给数据库。
