DBeaver无UI“只读”开关，需通过JDBC连接参数（如readOnly=true）或服务端权限控制；界面禁用编辑是因未读取唯一键元数据，非真正只读。
连接配置里没“只读”开关，得靠连接参数控制
DBeaver 本身没有 UI 上的「只读连接」复选框或标签，所谓“只读”，是通过 JDBC 连接字符串里的参数或数据源级别的只读设置生效的。它不会自动识别你连的是主库还是从库，也不会根据用户权限反推只读状态——一切取决于你填的参数和数据库服务端的实际策略。
常见做法是显式加上 readOnly=true 参数（对 PostgreSQL/MySQL 等多数 JDBC 驱动有效），或者在连接创建后手动调用 setReadOnly(true)（部分驱动支持运行时切换）。但要注意：这个参数只是向驱动和 JDBC 层声明意图，最终是否真不可写，还取决于数据库用户的实际权限和服务器配置。
- PostgreSQL 示例连接 URL：
jdbc:postgresql://host:5432/db?readOnly=true¤tSchema=public - MySQL 示例：
jdbc:mysql://host:3306/db?serverTimezone=UTC&useSSL=false&readOnly=true - Oracle 不认
readOnly=true，需改用oracle.jdbc.readOnly=true或依赖用户权限
为什么勾掉“读取唯一键”会让结果集变只读
这不是连接层的只读，而是 DBeaver 客户端内部的数据编辑能力开关。当你在 窗口 → 首选项 → 数据库 → 编辑器 → 数据编辑器 中取消勾选 读取数据表元数据(唯一键)，DBeaver 就无法确定哪一列或哪几列能构成主键/唯一约束，于是它不敢给你提供“双击编辑”“新增行”“删除行”等操作入口——因为没有唯一标识，它没法安全生成 UPDATE/DELETE 语句。
这种只读是界面级的、临时的、可逆的，不影响你执行任意 SQL（包括 INSERT/UPDATE），也不影响连接本身的读写能力。
- 现象：结果集表格里所有单元格变灰、右键无“编辑”菜单、工具栏“保存更改”按钮禁用
- 本质：DBeaver 放弃了对当前结果集的变更追踪能力，不是 JDBC 层拒绝写入
- 风险点：如果你误以为“界面不能改 = 连接只读”，可能在脚本里误发 DML 而没意识到权限其实允许
如何快速识别一个连接是不是只读（客户端视角）
最直接的办法是看连接建立后，SQL 编辑器右下角的状态栏是否显示 READ ONLY 字样。这个标记是 DBeaver 根据 JDBC 的 Connection.isReadOnly() 方法返回值动态渲染的，前提是驱动正确实现了该接口。
如果没显示，别急着下结论——可以手动验证：
- 执行一条简单
UPDATE（如UPDATE pg_database SET datlastsysoid = datlastsysoid WHERE false），看是否报错ERROR: cannot execute UPDATE in a read-only transaction（PostgreSQL）或类似提示 - 在连接上右键 →
编辑连接配置→ 切到驱动属性标签页，检查是否存在readOnly或等效 key，值是否为true - 打开
SQL 控制台，运行SHOW default_transaction_read_only;（PostgreSQL）或SELECT @@global.read_only;（MySQL），确认服务端是否强制只读
团队共享连接时，只读状态容易被忽略的细节
共享连接配置（.dbeaver-data-sources.json）默认不包含运行时只读状态，readOnly=true 这类参数如果写在连接 URL 里，会被同步；但如果只在 UI 里勾选了“只读连接”（某些旧版有该选项），或仅靠服务端权限控制，这些信息不会进配置文件，换机器、换人之后极易失效。
更隐蔽的问题是：同一个连接，不同用户用不同账号登录，只读表现可能完全不同。比如 DBA 账号连上去能写，应用账号连上去因权限限制只能读——DBeaver 不会帮你校验账号权限，它只反映当前连接的实际能力。
所以真正可靠的只读标记，必须落在连接参数里（readOnly=true）、服务端配置里（如 PostgreSQL 的 default_transaction_read_only = on），或者靠权限体系兜底。靠界面设置或个人记忆，不出问题才怪。
