DBeaver本身不提供临时授权功能，仅是执行GRANT/REVOKE语句的客户端工具；其界面无图形化权限配置选项，所有权限操作须在服务端通过SQL手动完成。
直接说结论：DBeaver 本身不提供“给用户加临时权限”的功能，它只是一个数据库客户端，没有权限管理能力；所谓“临时授权”，必须在数据库服务端执行 SQL 命令（如 GRANT / REVOKE），DBeaver 只是帮你执行这些语句的工具。
为什么在 DBeaver 里点不出“授权按钮”
DBeaver 的界面中没有“用户管理→点击授权→勾选 SELECT”这类图形化权限配置面板。它的权限相关操作全部依赖后端数据库的原生命令。MySQL 和 PostgreSQL 的权限模型差异大，DBeaver 不做抽象封装——它不会替你生成 GRANT SELECT ON mydb.* TO 'u1'@'%'，也不会校验语法是否合法。
- 你看到的“用户”节点（比如 MySQL 下的
mysql.user表）只是只读视图，双击打不开编辑界面 - 右键菜单里没有 “Grant privileges” 或 “Add permission” 选项
- 试图拖拽表到用户节点、或在连接属性里找“临时权限开关”，都会落空
真正可行的临时授权操作路径
用 DBeaver 连接一个有 GRANT OPTION 权限的高权限账号（如 root 或 DBA 账户），在 SQL 编辑器中手动执行授权语句。关键在于控制作用域和时效性：
- 限定数据库范围：
GRANT SELECT ON myapp_db.* TO 'dev_user'@'localhost';（避免写成ON *.*） - 限定表级粒度（更安全）：
GRANT INSERT, UPDATE ON myapp_db.orders TO 'batch_job'@'%'; - MySQL 8.0+ 支持角色：
CREATE ROLE 'report_role'; GRANT SELECT ON sales_db.* TO 'report_role'; GRANT 'report_role' TO 'analyst'@'%'; - PostgreSQL 中没有“临时权限”机制，但可配合
SET LOCAL ROLE在单个事务内切换权限上下文（需提前授予权限） - 撤销时别用
DROP USER，优先用REVOKE SELECT ON ... FROM ...;，避免误删认证信息
容易被忽略的坑：权限生效延迟与 host 匹配
即使 SQL 执行成功，用户仍连不上或报 Access denied，大概率卡在这两个细节：
- MySQL 的
host字段必须完全匹配：授权给了'user'@'192.168.1.%'，但用户从192.168.2.100连，就失败；'user'@'%'不等于'user'@'localhost'（Unix socket 连接走的是后者） - 权限变更后，MySQL 需要
FLUSH PRIVILEGES;（仅当直接改mysql.user表时才强制需要；用GRANT语句则自动刷新） - PostgreSQL 中
USAGE ON SCHEMA是前提：即使给了表SELECT，没给所在 schema 的USAGE，照样查不到元数据，DBeaver 左侧树也为空 - DBeaver 连接池可能复用旧会话：改完权限后，需右键连接 → “Disconnect” 再 “Connect”，不能只点“刷新”
最常被跳过的动作，是确认 SHOW GRANTS FOR 'user'@'host'; 的输出是否真包含你刚授的权限——别凭记忆，一定要查。
