DBeaver不提供权限继承关系的可视化图，仅显示显式授予的权限；PostgreSQL需用递归SQL查pg_auth_members，MySQL需结合SHOW GRANTS与role_edges表手动验证。
在 DBeaver 里看不到权限继承关系的可视化图
DBeaver 本身不提供「权限继承关系图」或「角色权限溯源树」这类图形化展示。它只显示当前用户/角色被直接授予的权限（比如 GRANT SELECT ON table_x TO role_a），但不会自动展开 role_a 是从 role_b 继承来的、而 role_b 又被 role_c 授予了哪些权限——这种多层嵌套的继承链，DBeaver 不解析、不渲染、也不缓存。
你右键一个用户 → “编辑权限”，看到的只是该用户对象上 显式执行过 GRANT 的那几条记录，和数据库实际生效的权限集可能有明显偏差。
查 PostgreSQL 权限继承必须用 SQL 手动追溯
PostgreSQL 的权限继承依赖 pg_auth_members 系统表，DBeaver 不会帮你自动拼查询。你需要自己运行类似下面的递归查询：
WITH RECURSIVE role_inheritance AS ( SELECT member, roleid, admin_option, 1 AS depth FROM pg_auth_members WHERE member = 'your_user'::regrole UNION ALL SELECT m.member, m.roleid, m.admin_option, ri.depth + 1 FROM pg_auth_members m INNER JOIN role_inheritance ri ON m.member = ri.roleid ) SELECT r.rolname AS role_name, ri.admin_option, ri.depth FROM role_inheritance ri JOIN pg_roles r ON ri.roleid = r.oid ORDER BY ri.depth;
这个查询能列出 your_user 通过哪些角色间接获得权限，以及是否带 WITH ADMIN OPTION。注意：rolname 是角色名，不是用户名；如果用户是直接登录角色，它也会出现在结果中（depth=1）。
- 把
'your_user'替换成你要查的实际用户名或角色名（加单引号） - 如果提示
regrole类型错误，改用(SELECT oid FROM pg_roles WHERE rolname = 'your_user') - DBeaver 执行时建议勾选“自动提交”，避免因事务隔离看不到最新授权状态
MySQL 没有标准的权限继承模型，DBeaver 更没法查
MySQL 8.0+ 支持角色（CREATE ROLE），但它的“继承”只是语义上的：角色 A 被赋予角色 B，用户再拥有 A，就等效于也拥有了 B 的权限。但 MySQL 没有类似 pg_auth_members 的系统视图暴露这种关系。
你只能靠两条命令交叉验证：
-
SHOW GRANTS FOR 'user'@'host';—— 查用户直接受到的 GRANT（含角色） -
SELECT * FROM mysql.role_edges WHERE TO_HOST = 'host' AND TO_USER = 'user';—— 查该用户被赋予了哪些角色（需有SELECT权限） - 再对每个角色单独执行
SHOW GRANTS FOR 'role_name'@'%';
DBeaver 的“编辑权限”面板只会显示第一条的结果，后两步必须手动切 SQL 编辑器执行。别指望它自动跳转或联动。
为什么 DBeaver 不做权限继承分析？
这不是功能缺失，而是设计取舍：
- 权限继承逻辑高度依赖数据库版本（如 PostgreSQL v14 新增
pg_read_all_data角色，v15 又调整了默认行为） - 跨 schema、跨 database 的权限叠加规则复杂（比如 USAGE on schema + SELECT on table ≠ 自动能看视图）
- DBeaver 定位是“SQL 客户端 + 元数据浏览器”，不是权限审计工具；真正需要审计的场景，通常要用专门的
pg_dumpacl或第三方合规平台
所以当你在 DBeaver 里发现某个表“明明没给权限却能查”，或者“给了权限却报错”，第一反应不该是点来点去找按钮，而是打开 SQL 编辑器，跑一条 SELECT has_table_privilege('user', 'schema.table', 'SELECT'); 看真实结果——这才是最接近数据库内核的判断方式。
