最可靠方式是在JDBC URL中添加readOnly=true参数，并在驱动属性中显式配置；同时须配合服务端只读权限（如PostgreSQL授SELECT权），仅靠DBeaver UI设置或关闭元数据读取无法真正限制SQL写操作。
怎么让 DBeaver 连接天然进入只读模式
直接控制连接行为最可靠的方式，是在 JDBC URL 里加 readOnly=true 参数。DBeaver 本身不提供全局“只读开关”，但每个连接的驱动属性中可以显式声明该参数，数据库驱动会据此拒绝写操作（如 INSERT、UPDATE、DELETE），并抛出类似 ERROR: cannot execute INSERT in a read-only transaction 的提示。
操作路径：右键连接 → 编辑连接 → 驱动属性 → 添加新属性：readOnly = true。注意不是勾选界面上的“只读”复选框（那个只是 UI 层面禁用编辑按钮，不防 SQL 手动执行）。
- PostgreSQL 连接需额外确认服务端未设
default_transaction_read_only=on，否则客户端参数可能被覆盖 - MySQL 连接要留意
read_only系统变量是否为ON，JDBC 的readOnly=true在服务端已只读时是冗余的，但加上更保险 - SQL Server 需配合数据库级
SET READ_ONLY或用户权限限制，仅靠 JDBC 参数效果有限
为什么关掉“读取唯一键”会让结果集变只读
DBeaver 的“读取数据表元数据(唯一键)”选项（位于 窗口 → 首选项 → 数据库 → 元数据）本质是让 DBeaver 获取主键或唯一约束信息。只有知道哪列能唯一标识一行，它才敢在结果集里启用行内编辑、删除、新增——否则无法生成准确的 WHERE 条件来定位目标行。
关掉它后，你看到的数据仍是可复制、可导出的，但右键菜单里没有“编辑”“保存”选项，双击单元格也不响应。这不是权限问题，是 DBeaver 主动放弃编辑能力。
- 这个设置影响所有连接，不能按连接单独开关
- 如果团队里有人需要编辑、有人只需查看，建议拆成两个连接配置：一个带元数据读取（开发用），一个关闭（只读共享用）
- 别指望靠这个实现安全隔离——用户仍可手动写
UPDATE语句执行，它只管 UI 层交互
用数据库权限 + DBeaver 配置双重锁定
真要让同事“只能看不能改”，必须从服务端权限入手。DBeaver 只是客户端，它不决定你能做什么，只反映你被允许做什么。给连接账号只授 SELECT 权限是最根本的防线。
以 PostgreSQL 为例：
GRANT CONNECT ON DATABASE mydb TO readonly_user; GRANT USAGE ON SCHEMA public TO readonly_user; GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonly_user;
之后再用该账号在 DBeaver 里建连接，即使误点编辑按钮或手写写操作 SQL，也会立刻报错 permission denied for table xxx。
- MySQL 同理：用
GRANT SELECT ON db.* TO 'user'@'%'; - 记得对新创建的表运行
ALTER DEFAULT PRIVILEGES（PG）或刷新权限（MySQL），否则后续表不自动继承 - DBeaver 里对应的连接用户名必须是这个只读账号，不能复用开发账号
共享只读连接配置时容易漏掉的点
团队共享 DBeaver 连接时，常以为导出 .dbeaver-data-sources.xml 就万事大吉，其实有三个关键项极易被忽略：
-
readOnly驱动属性没设——导出的 XML 里默认不包含它，得手动加 - 连接名没加前缀（如
[RO] prod-analytics），别人导入后可能误点进可写环境 - 没关掉“自动提交”（
autoCommit设为false）——虽然只读用户执行 DML 会失败，但开启 autoCommit 会让失败更隐蔽（比如批量查询中途断开时状态难追溯）
最稳妥的做法是：建好只读连接 → 手动验证执行一条 UPDATE 确实报错 → 再导出配置 → 把导出文件里的
