Oracle 23c 的 GRANT SELECT ANY TABLE ON SCHEMA HR TO BOB 不能直接用于 Java 应用连接池自动生效；Java 程序仍需以被授权用户（如 BOB）登录，且该用户必须已显式获得 CREATE SESSION 等基础权限，Schema 级授权仅控制可查对象范围，不替代连接能力。
Oracle 23c 的 GRANT SELECT ANY TABLE ON SCHEMA 能否直接用于 Java 应用连接池？
不能直接“自动生效”，java 程序仍需用被授权用户（如 bob）登录，且该用户必须已显式获得 create session 等基础权限。schema 级授权本身不替代连接能力，只控制「能查哪些对象」。
常见错误现象：ORA-01031: insufficient privileges —— 这往往不是因为没授 Schema 权限，而是漏了 GRANT CREATE SESSION TO BOB 或 GRANT CONNECT TO BOB。
-
GRANT SELECT ANY TABLE ON SCHEMA HR TO BOB只赋予对HR下所有当前及未来表/视图的查询权，不包含 DML、DDL 或跨 schema 访问能力 - 若 Java 应用使用
spring.datasource.username=BOB，则只需确保该用户具备CREATE SESSION+ Schema 级查询权即可，无需为每张新表单独补授权 - 注意：
SELECT ANY TABLE（无ON SCHEMA）仍是危险的旧方式，会穿透所有 schema，23c 中应避免使用
如何在 Java Spring Boot 中安全配置多 schema 场景下的权限？
典型场景是应用 schema（如 APP_USER）只读访问数据 schema（如 HR, FINANCE），此时应为每个目标 schema 单独授权，而非合并授予。
实操建议：
- 对每个数据 schema 执行独立授权：
GRANT SELECT ANY TABLE ON SCHEMA HR TO APP_USER、GRANT SELECT ANY TABLE ON SCHEMA FINANCE TO APP_USER - 避免使用
GRANT SELECT ANY TABLE TO APP_USER—— 它绕过 schema 边界，违反最小权限原则 - 如果应用需写入，改用细粒度对象级授权（如
GRANT INSERT, UPDATE ON HR.EMPLOYEES TO APP_USER），因为 23c 当前不支持INSERT ANY TABLE ON SCHEMA - Spring Boot 的
application.yml中保持单数据源配置，schema 切换靠 SQL 中的HR.EMPLOYEES显式限定，不依赖默认 schema 切换
ON SCHEMA 授权后，Java 应用查不到新表？检查这三处
Schema 级权限虽支持自动覆盖新增对象，但实际查不到常因缓存、权限延迟或语法问题导致。
立即学习“Java免费学习笔记（深入）”；
- 确认新表确实在目标 schema 下：
SELECT owner, object_name FROM all_objects WHERE object_type = 'TABLE' AND owner = 'HR'，别误建在APP_USER下 - 检查 Java 代码是否用了带 schema 前缀的 SQL：
SELECT * FROM HR.NEW_TABLE—— 若省略HR.且未设current_schema，会查当前用户 schema 下同名表（可能不存在） - Oracle 权限生效不依赖刷新或重启，但某些 JDBC 驱动版本（如 ojdbc8 ojdbc11 或至少
ojdbc8-21.10.0.0.1可规避
为什么 GRANT ANY SCHEMA 权限不该给应用账号？
这是管理权限，不是运行权限。普通应用账号（如 APP_USER）绝不需要它，只有 DBA 或运维账号才应持有。
容易踩的坑：
-
GRANT ANY SCHEMA允许用户对任意 schema 执行GRANT ... ON SCHEMA，等价于把整个数据库的 schema 级权限分发权交出去 - 即便应用账号只被授予
GRANT ANY SCHEMA，它也能立刻给自己加GRANT SELECT ANY TABLE ON SCHEMA SYS TO APP_USER，从而读取数据字典甚至密码哈希 - 正确做法：DBA 统一执行 schema 授权，应用账号仅持运行时所需权限（
CREATE SESSION+ 若干ON SCHEMA授权）
最易被忽略的一点：Schema 级权限不继承 synonyms 或 views 的 underlying object 权限 —— 如果 view 查询了其他 schema 的表，仍需额外授权，这点和传统对象权限一致。
