GRANT SELECT ANY TABLE ON SCHEMA 仅省对象级授权，不授连接权、不改默认schema、不绕过SQL前缀；需显式授CREATE SESSION，Java应用须用被授权用户连接，且SQL需带schema前缀。
GRANT SELECT ANY TABLE ON SCHEMA 语法是否真能省事？
能省，但只省对象级授权这一步——它不自动给连接权、不改默认 schema、不绕过 SQL 中的 schema 前缀。你写 SELECT * FROM EMPLOYEES，Oracle 仍按当前用户（如 BOB）的默认 schema 查找，不是去 HR 下找。
常见错误现象：ORA-00942: table or view does not exist，查了半天权限，结果是 SQL 没写 HR.EMPLOYEES；或者 ORA-01031: insufficient privileges，其实只是漏了 GRANT CREATE SESSION TO BOB。
- 必须显式授予
CREATE SESSION，GRANT CONNECT TO BOB虽可用，但该角色在 23c 中已降权为仅含此权限，不如直授清晰 - Java 应用连接池（如 HikariCP）中，
spring.datasource.username必须设为被授权用户（如BOB），不能靠SYS登录后切换 - JDBC URL 中加
¤tSchema=HR无效——Oracle 不支持该参数，会静默忽略
多 schema 场景下怎么安全授权？
一个应用要读 HR 和 FINANCE 两个 schema，不能靠一条 GRANT SELECT ANY TABLE TO APP_USER 一揽子解决——那是穿透所有 schema 的旧方式，23c 明确不推荐，且违反最小权限原则。
正确做法是分拆、显式、按需授权：
GRANT SELECT ANY TABLE ON SCHEMA HR TO APP_USERGRANT SELECT ANY TABLE ON SCHEMA FINANCE TO APP_USER- 若需写入，改用细粒度授权，例如
GRANT INSERT, UPDATE ON HR.EMPLOYEES TO APP_USER——23c 当前不支持INSERT ANY TABLE ON SCHEMA
注意：授权后新建的表会自动纳入权限范围，但前提是建在目标 schema（如 HR）下，而不是误建在应用用户（如 APP_USER）下。
Java 应用查不到新表？先核对这三处
Schema 级权限虽支持自动覆盖新建对象，但实际查不到往往卡在非权限环节：
- 确认表确实建在目标 schema 下：
SELECT owner, object_name FROM all_objects WHERE object_type = 'TABLE' AND owner = 'HR' - 检查 Java 代码中 SQL 是否显式带 schema 前缀，例如写成
SELECT * FROM HR.EMPLOYEES，而非仅EMPLOYEES - 刚授完权就查，可能遇毫秒级缓存延迟；可加一句
SELECT 1 FROM DUAL触发 session 刷新，或稍等再试
为什么 DBA_SEGMENTS 里看不到自动索引段？
这不是 Schema Privileges 的问题，但常被混淆——23c（即 23ai）的自动索引默认是关闭的（AUTO_INDEX_MODE = OFF），即使启用为 IMPLEMENT，也采用延迟物理构建：首次访问才生成 INDEX 段，所以 DBA_SEGMENTS 长期不可见。
别拿 19c 的行为套 23c：DBA_AUTO_INDEX_EXECUTIONS 在 23c 中可能返回空或仅记录“评估未执行”，不代表没生效，而是尚未触发物理构建。
真正要验证段行为，得关掉自动机制，统一用人工方式：EXEC DBMS_AUTO_INDEX.CONFIGURE('AUTO_INDEX_MODE','OFF')，再调用 DBMS_AUTO_INDEX.REPORT_LAST_ACTIVITY 提取建议，最后手工执行 CREATE INDEX——这时段生成逻辑和传统索引完全一致，DBA_SEGMENTS 立即可见。
