答案：DBeaver无法图形化查看用户权限，必须执行SQL查询；MySQL用SHOW GRANTS FOR 'user'@'host'（或SHOW GRANTS查看当前用户），PostgreSQL需组合查pg_roles和pg_auth_members等系统表。
直接在 DBeaver 里查不到用户权限的完整列表——它不提供类似 SHOW GRANTS 的图形化权限面板，所有权限信息必须靠 SQL 查询获取。
MySQL：用 SHOW GRANTS 查指定用户的全部权限
这是最直接、最可靠的方式。DBeaver 的 SQL 编辑器能执行，结果也清晰易读：
- 连接目标数据库后，在 SQL 编辑器中运行：
SHOW GRANTS FOR 'username'@'host'; - 如果不确定
host，可先查SELECT User, Host FROM mysql.user;确认完整用户名格式 - 注意：必须有
SELECT权限访问mysql.user表，否则会报错Access denied；普通账号通常看不到其他用户的权限 - 若只关心当前登录用户，可简写为：
SHOW GRANTS;（不带FOR）
PostgreSQL：查 pg_roles 和 pg_auth_members 组合权限
PostgreSQL 没有等价于 SHOW GRANTS 的单条命令，需组合查询系统表：
- 查用户自身角色和直接权限：
SELECT rolname, rolsuper, rolcreatedb, rolcreaterole FROM pg_roles WHERE rolname = 'username'; - 查该用户所属的角色组：
SELECT roleid::regrole, member::regrole FROM pg_auth_members WHERE member = 'username'::regrole; - 查对特定 schema 的 USAGE 权限：
SELECT schema_name, has_schema_privilege('username', schema_name, 'USAGE') FROM pg_namespace WHERE nspname NOT LIKE 'pg_%'; - 注意：
pg_catalog下多数权限视图（如information_schema.role_table_grants）默认只返回当前用户有权限看到的对象，不是全量
DBeaver 自身不缓存或解析权限，别依赖“连接属性”里的用户字段
很多人误以为右键连接 → “编辑连接” → “用户”栏显示的用户名就代表它拥有对应权限，其实这只是认证凭据。DBeaver 不会主动校验或展示该用户实际被授予了哪些权限：
- 连接成功 ≠ 权限完备：TCP 连通、密码正确、认证通过后，DBeaver 才开始发元数据查询（如
SELECT * FROM information_schema.tables），这时才真正触发权限检查 - “权限不足”错误往往出现在左侧导航树加载阶段，而非连接弹窗里——说明问题出在会话级授权，不是登录失败
- 如果你改了数据库用户权限，必须在 DBeaver 中断开重连，或者手动刷新元数据（右键连接 → “刷新元数据”），否则旧的失败状态可能残留
查不到权限时，优先确认你有没有查权限的权限
这是最容易卡住的地方。很多开发账号被严格限制，连 mysql.user 或 pg_roles 都不可 SELECT：
- MySQL 中，至少需要
SELECT权限在mysql库，才能运行SHOW GRANTS；否则只能让 DBA 帮你查 - PostgreSQL 中，普通用户默认看不到
pg_authid或pg_roles的敏感字段（如rolpassword），但rolname、rolsuper等非敏感字段通常可见 - 如果连
information_schema都查不了（比如 MySQL 报Access denied for user ... to database 'information_schema'），说明账号被显式拒绝了系统库访问，这种限制无法绕过，只能提权或换账号
