DBeaver中执行GRANT SELECT前须确认数据库类型及权限模型：PostgreSQL需先授USAGE ON SCHEMA，MySQL需显式授予information_schema等系统库权限，且DBeaver“连接成功”不等于“权限就绪”，元数据加载失败即表明schema或catalog层级缺权限。
DBeaver里执行GRANT SELECT必须先确认数据库类型和权限模型
不同数据库对GRANT SELECT的语法、作用域和前提条件差异极大。比如 PostgreSQL 要求用户先有 USAGE ON SCHEMA 才能查该 schema 下的表；而 MySQL 的 GRANT SELECT ON db.table 不会自动赋予 SELECT ON db.*，更不隐含对 information_schema 的访问权。DBeaver 本身不翻译或补全权限语句——它只是把你的 SQL 原样发给数据库执行。所以第一步不是点按钮，而是看清楚你连的是哪种库、目标对象在哪个层级（database / schema / table）、当前用户有没有足够权限去授。
PostgreSQL中GRANT SELECT失败的常见原因
- 没提前执行
GRANT USAGE ON SCHEMA public TO username—— 即使表在public下，没 schema usage 权限也会报permission denied for schema public - 用
GRANT SELECT ON ALL TABLES IN SCHEMA public TO username但忘了后续新建的表不会自动继承，得配合ALTER DEFAULT PRIVILEGES - 用户是通过角色（role）间接获得权限的，但没用
SET ROLE切换，导致 DBeaver 当前会话看不到已授的表 - 执行
GRANT的账号本身没CREATEROLE或对应对象的GRANT OPTION，直接被拒绝，错误类似must be owner of relation xxx
MySQL里GRANT SELECT后仍报错“SELECT command denied”的典型场景
- 只授了
GRANT SELECT ON mydb.mytable，但 DBeaver 启动时默认执行SELECT * FROM information_schema.tables—— 这需要单独的SELECT权限或SHOW DATABASES权限 - 用户 host 是
'user'@'192.168.1.%'，但连接时 DBeaver 填的是localhost，实际匹配到'user'@'localhost'这个无权限的记录 - 执行完
GRANT没运行FLUSH PRIVILEGES（虽然 8.0+ 多数情况不需要，但某些配置下仍必要） - 表名含反引号或大小写敏感，而
GRANT语句里漏写了，例如真实表名是`UserLog`，却写了GRANT SELECT ON mydb.userlog
在DBeaver里安全执行GRANT SELECT的操作建议
- 不要依赖“可视化权限面板”一键授权——它底层生成的 SQL 经常省略 schema 层级或忽略系统 catalog 访问需求，尤其对 PostgreSQL 和 RisingWave
- 先用管理员账号（如
postgres或root）连上，在 SQL 编辑器里手动写并验证：SELECT COUNT(*) FROM pg_tables（PG）或SELECT 1 FROM information_schema.schemata LIMIT 1（MySQL） - 授完权立刻换目标用户连接测试，别只在当前会话里
SET SESSION AUTHORIZATION模拟——DBeaver 的元数据加载逻辑可能绕过会话切换 - RisingWave 等新兴数据库需额外注意：它不兼容传统
information_schema查询，DBeaver 可能因探测失败直接卡住导航树，此时必须显式授予SELECT ON rw_catalog.rw_tables类似路径
最易被忽略的一点：DBeaver 的“连接成功”不等于“权限就绪”。只要它左侧树形导航加载不出表名、双击表提示“权限不足”，哪怕 SELECT 1 能跑通，也说明元数据访问链路上某处缺权限——这往往不是表本身，而是 schema、catalog 或视图定义的读取权。
