生产环境必须禁用DBeaver数据编辑，唯一可靠方式是在连接配置中显式设置JDBC只读参数（如MySQL加readOnly=true），该参数由驱动层强制拦截写操作，而非依赖界面开关或人为谨慎。
生产环境必须禁用数据编辑，这不是可选项，而是安全底线。 DBeaver 默认允许双击单元格直接修改数据并提交，一旦误点“保存”或触发自动提交，没有回滚机制，后果不可逆。它不提供行级或语句级的确认弹窗，也不记录谁改了哪一行——这点和命令行客户端或审计型工具完全不同。
为什么不能靠“人不手贱”来防误操作
真实故障里，80% 的生产数据误改不是故意的，而是：在多标签页间快速切换时点错表、用错连接（比如开发连接连上了生产库）、脚本执行后顺手点开结果集又顺手改了一行、甚至只是鼠标划过时双击了某个单元格。DBeaver 的编辑行为是“即时生效+无二次确认”的，只要连接有 UPDATE 权限，就具备破坏能力。
- 它不会区分“当前连接标的是【生产】还是【测试】”，只认 JDBC URL 和账号权限
- “只读模式”开关（
Read-only connection）只影响 SQL 编辑器执行，对数据面板双击编辑无效 - 即使关闭了
Auto-commit，手动点击“保存”仍会提交事务，且没有撤销按钮
全局禁用数据编辑的唯一可靠方式：设置连接级只读参数
DBeaver 的数据编辑行为由 JDBC 驱动层控制，真正起效的是连接参数，而不是界面开关。对 MySQL、PostgreSQL、Oracle 等主流数据库，必须在连接配置中显式传入只读标识：
- MySQL：在连接属性的
Driver properties里添加readOnly=true - PostgreSQL：添加
readOnly=true或在 JDBC URL 后追加?readOnly=true - Oracle：添加
oracle.jdbc.readOnly=true - 达梦 DM8：添加
readOnly=true
⚠️ 注意：readOnly=true 是 JDBC 标准参数，但部分旧版驱动（如 MySQL Connector/J 5.1.x）可能忽略它。务必验证：建好连接后，右键表 → “查看数据”，尝试双击任意单元格——光标不应变为可编辑状态，且右下角状态栏应显示 Read-only。
别信“禁用保存按钮”这种表面操作
有人试图通过取消勾选 Auto-commit、隐藏工具栏“保存”按钮、甚至修改 UI 主题把保存图标变灰来“防误触”。这些全无效：
- 双击编辑后按
Ctrl+S仍能保存 - 右键单元格菜单里“提交更改”依然可用
- 切换到其他标签页再切回来，编辑态仍保留
- UI 隐藏不等于功能禁用，快捷键和上下文菜单照常工作
真正的防护必须落在连接建立那一刻：让 JDBC 驱动从源头拒绝任何写操作。这是唯一被 JDBC 规范保证的行为，也是所有合规审计要求的基线配置。
额外加固：用专用只读账号 + 连接名强标识
参数级只读是技术兜底，但还需配合管理手段：
- 生产连接必须使用权限最小化的账号，仅授予
SELECT，禁止INSERT/UPDATE/DELETE/ALTER - 连接名称强制包含环境标识，例如
PROD_MySQL_app_core_v8，避免靠记忆识别 - 在工作空间设置里启用
Confirm before executing DDL statements，虽然对 DML 编辑无效，但至少堵住建表删表类高危操作
最危险的不是功能太强，而是你不知道它什么时候悄悄越过了你的预期。DBeaver 的编辑能力在开发环境是效率利器，在生产环境就是裸露的引信——把它焊死在只读状态，不是限制工具，而是守住边界。
