不能直接授予SELECT ANY TABLE，因其赋予用户查询所有schema下所有表（含未来新建）的高危权限，且无法按schema或表名回收，运维成本高；应创建最小权限只读角色，通过角色封装+对象授权实现可控只读。
为什么不能直接 GRANT SELECT ANY TABLE
直接执行 grant select any table to user_name 看似一步到位，但实际是高危操作：它让该用户能查当前库中所有 schema 下所有普通表（包括未来新建的），且无法按 schema 或表名做回收控制。更麻烦的是，select any table 是系统级权限，不支持 with grant option 以外的细粒度约束，一旦误授，只能整权收回或逐个清理对象权限，运维成本陡增。
怎么创建最小权限的只读角色
核心思路是「角色封装 + 对象授权」，把权限收口到角色里，再把角色给用户。这样后续增删表权限只需改角色，不影响用户本身。
- 先建角色：
CREATE ROLE app_readonly; - 必须在目标 schema 下执行，或用 DBA 身份批量生成授权语句：
SELECT 'GRANT SELECT ON ' || owner || '.' || table_name || ' TO app_readonly;' FROM dba_tables WHERE owner IN ('APP_SCHEMA', 'CONFIG_SCHEMA'); - 执行生成的每条
GRANT SELECT ON ... TO app_readonly;（注意不是GRANT SELECT ANY TABLE） - 最后把角色赋给用户：
GRANT app_readonly TO readonly_user;
别忘了基础登录权限和锁账号
只读角色只管数据访问，用户连不上库等于白搭。新用户必须显式获得连接能力，且生产环境应禁用交互式登录：
-
GRANT CREATE SESSION TO readonly_user;—— 否则报错ORA-01045: user ... is not authorized to log on -
ALTER USER readonly_user ACCOUNT LOCK;—— 防止用户用 SQL*Plus 或其他客户端手动登录 -
ALTER USER readonly_user PASSWORD EXPIRE;—— 强制首次连接时改密（如需交互场景）
视图、同义词和数据字典容易被忽略
只读角色默认不包含对视图、物化视图或同义词的访问权。如果应用依赖 SELECT FROM v$session 或自定义视图，得单独授权：
- 查动态性能视图（如
v$session）需额外授SELECT_CATALOG_ROLE，但该角色含大量隐式权限，慎用；更安全的做法是创建具体视图并授SELECT权限 - 同义词本身不继承底层对象权限，必须对同义词指向的原表/视图单独授权
- 数据字典表（如
dba_tables）属系统对象，普通只读角色无法访问，除非显式授SELECT ANY DICTIONARY（极不推荐）
真正可控的只读，从来不是靠“禁止写”，而是靠“只开读的门”。漏掉一个视图、一个同义词、一个 session 权限，都可能让只读策略形同虚设。
