DBeaver默认编辑会全表更新，是因为查询结果未包含主键或唯一字段，导致无法定位单行，遂弹窗让用户选择“应用到所有行”；必须启用只读连接、safeUpdates/readonly驱动参数及确认修改和WHERE条件等三项保护设置。
为什么DBeaver默认编辑会全表更新
直接双击单元格修改数据时，DBeaver 不是靠主键定位单行，而是依赖“结果集里是否包含主键或唯一约束字段”。如果查询语句没选主键（比如只写 SELECT name FROM users），它就无法确定你改的是哪一行，于是弹出提示框让你选“应用到所有行”——点确认就真会执行 UPDATE users SET name = ? 全表覆盖。
必须开启的三项保护设置
这些不是可选项，是防误操作的底线配置：
- 在连接设置 → SQL Execution 标签页中，勾选
Read-only connection：连生产库时强制只读，连上即锁死写权限 - 在连接设置 → Drivers → 编辑对应驱动 →
Driver properties里添加：safeUpdates=true（MySQL）或readonly=true（PostgreSQL），让 JDBC 层也拦截危险操作 - 在全局设置 → Editors → Data Editor → 勾选
Confirm data changes和Use WHERE clause for UPDATE/DELETE：每次修改前强制弹窗确认，并自动拼 WHERE 条件（前提是结果集含主键）
DBeaver里怎么验证当前连接是否真安全
别信界面上写的“Connected”，得看实际行为和权限反馈：
- 执行
SELECT @@sql_safe_updates;（MySQL）或SHOW transaction_read_only;（PostgreSQL），返回1或on才算生效 - 尝试执行
UPDATE users SET status=1;（不带 WHERE），应立刻报错，而不是弹确认框 - 右键表 → Edit Table → 如果菜单灰掉或提示“Connection is read-only”，说明
Read-only connection已起作用 - 注意：某些 ORM 集成模式（如 Django 的 dbshell）可能绕过这些设置，所以生产环境务必用独立连接配置，不要复用开发连接
生产库连接必须带环境标识且隔离
再强的客户端设置也防不住连错库。真正兜底的是连接命名和 DNS 隔离：
- 连接名必须包含环境，比如
mysql-prod-ro、pg-staging-rw，DBeaver 左侧导航栏一眼能分辨 - 主机名不能写 IP 或
localhost，必须用语义化域名如mysql-prod.example.com，由 DNS 解析到真实地址——这样即使配置被复制，也能靠域名阻断误连 - 工作空间目录单独建
prod-workspace，和 dev/staging 物理隔离，避免手滑点错连接 - IDE 或终端标签页颜色标记（如红色标题栏）比任何弹窗都早一步提醒你正在操作生产环境
真正的保护不在“点了保存会不会弹窗”，而在“你点之前就知道自己不该点”。客户端设置只是最后一道闸门，前面的环境命名、DNS 隔离、账号权限、连接分组，每少做一环，闸门就被冲开一次。
