DBeaver不提供独立的“授予权限”功能，仅透传数据库原生权限管理能力；授权操作需通过SQL编辑器执行GRANT语句，并确保当前用户有GRANT OPTION、目标角色存在、权限粒度匹配。
DBeaver 本身不提供“给角色授权”的功能，它只是把数据库的权限管理能力透传出来——真正执行授权的是你连接的数据库（MySQL/PostgreSQL/Oracle等），DBeaver 只负责帮你写对 SQL、点对按钮、避开隐式权限陷阱。
为什么在 DBeaver 里找不到“授予权限”菜单？
DBeaver 的 UI 设计遵循 JDBC 驱动能力边界：它不会自己实现一套权限模型，而是依赖后端数据库返回的元数据和可执行语句。比如：
- MySQL 用户/角色管理分散在
mysql.user、mysql.role_edges等系统表，DBeaver 不会主动渲染“角色授权向导”； - PostgreSQL 从 v14 起支持
pg_read_all_data这类预定义角色，但 DBeaver 不会自动识别或推荐——它只允许你右键点击某个角色 → “Edit Role”，然后手动填入INHERIT、CREATEROLE等属性； - Oracle 的
GRANT ... TO ROLE语法完全合法，但 DBeaver 的对象浏览器默认不展开“Role Privileges”节点，除非你手动刷新或启用高级元数据模式。
在 DBeaver 中安全执行 GRANT 的三个前提
直接写 GRANT 语句没问题，但容易因上下文缺失导致失败。务必确认以下三点：
- 当前连接用户具有
GRANT OPTION（MySQL）或WITH ADMIN OPTION（PostgreSQL/Oracle）——否则报错ERROR 1045 (28000): Access denied或permission denied for database； - 目标角色已存在：
SELECT rolname FROM pg_roles（PG）、SELECT User,Host FROM mysql.user（MySQL）； - 权限粒度匹配：MySQL 中对库授权用
GRANT SELECT ON `db_name`.* TO 'role_name'@'%'，而 PostgreSQL 必须先GRANT USAGE ON SCHEMA public TO role_name，再GRANT SELECT ON ALL TABLES IN SCHEMA public TO role_name。
绕过 UI 限制：用 SQL 编辑器精准授予权限
DBeaver 的 SQL 编辑器是权限配置最可靠的方式，尤其适合跨库、批量或带条件的授权场景：
- MySQL 8+ 创建角色并授权：
CREATE ROLE 'app_reader';<br>GRANT SELECT ON `sales_db`.* TO 'app_reader';<br>GRANT 'app_reader' TO 'dev_user'@'localhost';
- PostgreSQL 授予系统级只读权限（v14+）：
CREATE ROLE app_reader;<br>GRANT pg_read_all_data TO app_reader;<br>GRANT app_reader TO dev_user;
- 注意：PostgreSQL 中
GRANT后必须执行SET ROLE app_reader或RESET ROLE才能验证效果，DBeaver 不会自动切换会话角色。
最容易被忽略的是权限生效时机：MySQL 需要 FLUSH PRIVILEGES（仅修改系统表时），PostgreSQL 权限立即生效但新会话才加载角色继承关系，Oracle 则依赖 ALTER SESSION SET CURRENT_SCHEMA 控制默认 schema。这些细节不写进 SQL 就容易以为“授权失败”。
