DBeaver权限验证需手动执行关键查询：MySQL查information_schema.tables、PostgreSQL查pg_catalog.pg_tables及目标表，因SHOW GRANTS仅显示声明权限而非实际可用权限，且连接测试成功不等于元数据访问正常。
直接在 DBeaver 里执行几条关键查询，比看 SHOW GRANTS 更快定位真实可用权限——因为 DBeaver 启动时会自动查 information_schema 或 pg_catalog，失败就报“权限不足”，但错误信息不告诉你具体卡在哪一步。
用 DBeaver 自带 SQL 编辑器跑验证语句
DBeaver 连接成功后，别急着点表，先开一个新 SQL 脚本（右键连接 → SQL 编辑器 → 新建 SQL 脚本），手动执行以下语句，观察哪条报错：
- MySQL：执行
SELECT COUNT(*) FROM information_schema.tables LIMIT 1;—— 如果失败，说明连information_schema都不可读，SHOW DATABASES权限大概率缺失 - PostgreSQL：执行
SELECT COUNT(*) FROM pg_catalog.pg_tables LIMIT 1;—— 失败则USAGE ON SCHEMA pg_catalog或pg_read_all_data角色没给 - 再试查自己库里的表：
SELECT * FROM your_table LIMIT 1;—— 成功说明对象级权限 OK，失败则需检查该表的SELECT授权是否明确授予
为什么 SHOW GRANTS 看起来有权限却还是报错
SHOW GRANTS FOR 'user'@'host' 返回的结果只是「声明过的权限」，不是「当前会话实际能用的权限」。常见脱节点：
- MySQL 中，用户被显式
REVOKE某权限后，SHOW GRANTS可能仍显示旧的合并结果（尤其跨 host 条目冲突时） - PostgreSQL 中，
USAGE ON SCHEMA public缺失会导致即使有表的SELECT权限也无法访问——因为 schema 层是前置门禁 - 某些数据库（如 OceanBase MySQL 模式）要求账号必须对目标 database 有
USAGE才能展开导航树，而SHOW GRANTS不体现 database 级绑定
绕过 DBeaver 自动元数据探测快速测试
如果你只想确认账号能否执行 SQL，不想被导航树初始化干扰，可以临时关闭 DBeaver 的自动元数据加载：
- 编辑连接 → 切换到 驱动属性 页签
- 添加或修改参数：
metadataCache=false（MySQL）、disableColumnStats=true（PostgreSQL） - 或者更彻底：在连接设置的 初始化脚本 里填
SELECT 1;，跳过默认的\dt/SHOW FULL TABLES类探测 - 这样连接成功后不会自动报错，你能干净地进 SQL 编辑器，自己控制查什么
真正容易被忽略的是：DBeaver 的「连接测试」只校验认证和基础会话（比如 SELECT 1），它不模拟后续元数据请求。所以“测试连接成功” ≠ “能展开表列表” ≠ “能执行任意查询”。权限验证必须落到具体操作路径上，而不是停留在 GRANT 语句层面。
