“权限不足”指连接成功但无法查看元数据，因会话级授权缺失；DBeaver自动查询information_schema或pg_catalog失败所致，需按数据库类型授予对应schema和系统视图权限。
“权限不足”不是连不上，而是连上了却看不到表、查不了元数据——DBeaver 的权限问题基本都出在会话级授权缺失，而不是连接配置错了。
为什么连上数据库后左侧导航树为空或报错“SELECT command denied”
DBeaver 连接成功后会自动执行系统查询（比如 SELECT * FROM information_schema.tables 或 SELECT * FROM pg_catalog.pg_tables）来加载库表结构。如果用户没被授予访问 information_schema（MySQL）或 pg_catalog（PostgreSQL）的权限，就会卡在这一步，表现为导航树空、右键无“刷新”、点开数据库节点报错。
- MySQL 中需确保用户有
SELECT权限 oninformation_schema.*，否则连SHOW DATABASES都可能失败 - PostgreSQL 中必须有
USAGEonpublicschema（或目标 schema），且SELECTonpg_catalog.pg_tables等关键视图；v14+ 可直接授pg_read_all_data角色 - Oracle 用户需有
SELECT_CATALOG_ROLE或显式GRANT SELECT ON sys.dba_tables TO user
在 DBeaver 里给用户加模式（schema）级权限的实际路径
别去“用户编辑”界面瞎点“权限”标签页——那个只管全局权限（如 CREATE TABLE），不控制对具体 schema 下对象的访问。真正起作用的是“模式权限”页签。
- 在数据库导航树中展开目标数据库 → 展开“用户”节点 → 双击要修改的用户
- 切换到
模式权限标签页（不是“权限”，也不是“角色”） - 勾选目标 schema（如
public、sales），再勾选右侧对应权限：常用的是USAGE（能看见该 schema 下的对象）和SELECT（能查表） - 点
保存→ 弹出 SQL 预览窗口 → 点执行，权限才真正写入数据库
注意：PostgreSQL 中，USAGE on schema 是前提；没有它，哪怕给了 SELECT on 表也无效。
用 DBeaver 创建角色并批量赋权比直接授用户权限更可靠
直接给用户授一堆零散权限容易漏、难回收。用角色封装是生产环境的标准做法，DBeaver 的角色管理界面就是为这个设计的。
- 导航树中展开数据库 → 右键“角色” → “新建角色”，填名称（如
app_reader） - 切到
权限标签页 → 勾选“Schema”下拉选中目标 schema → 再勾选SELECT、INSERT等（注意：这里才是真正的对象级权限设置入口） - 保存角色后，回到“用户”节点 → 编辑目标用户 → 切到
角色标签页 → 把刚建的角色拖进去或从列表选中 - 确认保存并执行，用户即继承角色所有权限
这种做法的好处是：权限变更只需改角色，不用逐个用户操作；审计时查角色比查用户更清晰；避免因误操作漏掉某个 schema 的 USAGE。
常见坑：SQL Server 和 MongoDB 的权限模型完全不兼容标准 SQL 界面
DBeaver 的通用权限 UI 对 SQL Server 和 MongoDB 几乎无效——它们的权限体系不走标准 GRANT/REVOKE 流程，DBeaver 的“模式权限”“角色”页签根本不会触发对应命令。
- SQL Server 用户必须用 T-SQL 显式执行：
GRANT SELECT ON OBJECT::[schema].[table] TO [user]，DBeaver 的图形界面不生成这类语句 - MongoDB 完全依赖 RBAC 角色（如
readWrite），得在admin库下用db.grantRolesToUser()手动赋权，DBeaver 连“用户”节点都可能不显示（取决于认证库配置） - 遇到这两类数据库报“权限不足”，第一反应不是调 DBeaver 设置，而是检查 MongoDB 的
--authenticationDatabase是否设对，或 SQL Server 登录是否映射到了数据库用户
真正容易被忽略的点是：DBeaver 的权限 UI 是“数据库方言感知”的，它只对 PostgreSQL、MySQL、Oracle 等支持标准 SQL 授权模型的数据库生效；一旦切到 SQL Server 或 MongoDB，界面上看到的选项基本是摆设，必须切到 SQL 编辑器手写命令。
