DBeaver不提供“一键复制用户权限”功能，因其权限管理仅为数据库原生GRANT/REVOKE语句的可视化封装，且各数据库（如PostgreSQL、MySQL）权限模型差异大，无法安全抽象通用逻辑；权限复制需手动SQL操作或配置文件间接迁移客户端连接设置。
DBeaver 本身不提供“一键复制用户权限”的功能，所有权限复制都必须手动操作或借助 SQL 实现。 它的图形界面只支持逐项查看、勾选和保存，没有「从 A 用户同步到 B 用户」的按钮或菜单项。想省事？得绕道 SQL 或导出配置再改。
为什么 DBeaver 没有“复制权限”按钮
DBeaver 的权限管理是基于数据库原生机制的可视化封装，不是独立的权限引擎。它只是把 GRANT / REVOKE 语句翻译成 UI 表单。PostgreSQL、MySQL、SQL Server 各自的权限模型差异太大（比如 PostgreSQL 有 USAGE on schema、DEFAULT PRIVILEGES，而 MySQL 没有 schema 级角色继承），DBeaver 不可能抽象出一个通用“复制”逻辑而不引入歧义或错误。
常见误解是：右键用户 → “编辑用户” → “角色”或“权限”页签里点几下就能同步——实际只是给当前用户增删角色/权限，不会读取另一个用户的配置。
用 SQL 批量复制角色和对象权限（最可靠）
如果你已知源用户 user_a 和目标用户 user_b，且数据库支持标准 SQL 权限语法（如 PostgreSQL、Oracle），可手写或生成授权语句：
- 先查源用户有哪些角色：
SELECT rolname FROM pg_roles r JOIN pg_auth_members m ON m.roleid = r.oid WHERE m.member = (SELECT oid FROM pg_roles WHERE rolname = 'user_a'); - 再对每个角色执行：
GRANT <role_name> TO user_b;</role_name> - 查对象级权限（如表 SELECT）：
SELECT 'GRANT SELECT ON ' || schemaname || '.' || tablename || ' TO user_b;' FROM pg_tables WHERE tableowner = 'user_a'; - 把结果复制执行——注意检查
schemaname是否为当前搜索路径所含 schema，避免漏授public外的 schema 权限
MySQL 不支持 GRANT ... TO ... WITH GRANT OPTION 的批量导出，需用 SHOW GRANTS FOR 'user_a'@'host'; 查原始语句，再替换用户名后执行。
通过 data-sources-auth.json 和 data-sources.json 间接“迁移”权限配置
这个方法只适用于你**在同一个数据库实例中，已有两个用户，且想让新用户拥有和旧用户完全一致的连接行为（比如默认 schema、驱动参数、SSL 设置等）**，但它不复制数据库服务端权限，仅复制 DBeaver 客户端侧的连接偏好：
- 关闭 DBeaver
- 打开
.dbeaver/data-sources.json，找到源用户的连接定义，复制整个 JSON 对象 - 粘贴并修改其中的
"name"、"configuration"/"connection"/"user"字段为新用户名 - 对应地，在
data-sources-auth.json中复制该连接的 auth 块，更新"userName"并确保加密密码字段仍有效（别手动改密文） - 重启 DBeaver，新连接会以新用户身份登录，但其数据库权限仍取决于服务端配置，不是从旧用户“继承”来的
这个操作容易踩坑：如果源用户有 DBA 角色而新用户没有，连上去也会报 permission denied，UI 不会预警。
容易被忽略的关键点
权限复制不是“拷贝粘贴”那么简单。PostgreSQL 中 GRANT USAGE ON SCHEMA public TO user_b 和 GRANT SELECT ON ALL TABLES IN SCHEMA public TO user_b 是两回事；后者不会自动覆盖后续新建的表，得配 ALTER DEFAULT PRIVILEGES。MySQL 里 GRANT SELECT ON db.* 不包含存储过程权限，得额外加 EXECUTE。这些细节 UI 不提示，全靠你写 SQL 时自己补全。
