直接赋权比角色赋权快，因权限校验仅在SQL硬解析时发生，直接授权缓存在会话权限向量中路径短；角色授权需遍历角色激活链、嵌套关系及字典表，增加微秒级延迟，高并发硬解析场景下尤为明显。
直接赋权比通过角色赋权快，但差异只在权限验证阶段，且仅对首次解析的 SQL 有可测影响
Oracle权限检查发生在SQL硬解析时
当一条 SQL 第一次执行（硬解析），Oracle 需要确认当前会话是否有权访问涉及的对象（如表、视图、函数）。这个检查过程不是“每次执行都查一遍”，而是发生在语句进入共享池前的权限校验环节。
- 直接授予的系统权限（如
SELECT ANY TABLE）或对象权限（如GRANT SELECT ON emp TO scott）会被缓存在会话的权限向量中，查询快、路径短 - 通过角色授予的权限（如
GRANT SELECT ON emp TO hr_role; GRANT hr_role TO scott）需额外走角色激活链：先查SESSION_ROLES确认哪些角色已启用 → 再查每个角色对应的权限 → 合并去重 → 最终生成有效权限集 - 若角色被
SET ROLE NONE关闭，或使用了密码保护角色（CREATE ROLE r1 IDENTIFIED BY pwd），该链路还会触发额外校验开销
角色嵌套和动态角色会放大延迟
角色不是扁平列表，它支持嵌套（A 角色包含 B 角色）、条件启用（如基于应用上下文）、甚至运行时动态切换。这些特性让权限判定逻辑更复杂，尤其在硬解析高峰期可能成为瓶颈点。
- 每层嵌套增加一次字典表访问（
ROLE_ROLE_PRIVS、ROLE_SYS_PRIVS、ROLE_TAB_PRIVS） -
authid current_user函数或DEFINER模式下触发的角色权限检查，会在每次调用时重新评估调用者角色状态 - 使用
ENABLE EDITION或多租户（CDB/PDB）环境时，角色作用域还需跨容器判断，进一步拖慢解析
实际影响通常被掩盖，但高并发场景下可见
单条 SQL 的权限检查耗时在微秒级，日常业务几乎感知不到。问题集中在两类场景：
- 大量不同用户的短连接频繁执行新 SQL（如 Web 应用未绑定变量、ORM 自动生成语句），导致硬解析率飙升，角色路径开销被放大
- 数据库启用了细粒度审计（FGA）或 Oracle Vault，权限检查会联动策略评估，此时角色链越长，延迟越明显
- 注意：
SESSION_PRIVS和SESSION_ROLES视图本身不慢，但它们背后的数据来源（SYS.SYSAUTH$、SYS.ROLEAUTH$等基表）在高并发下可能成为争用点
真正容易被忽略的是：这种性能差异不会出现在 EXPLAIN PLAN 或 AWR 报告里，它藏在 PARSE TIME ELAPSED 和 PARSE COUNT (hard) 这两个指标背后。如果你发现硬解析平均耗时异常升高，且用户普遍使用角色而非直接授权，值得抓几个 v$sql 记录对比 PARSING_USER_ID 和 PARSING_SCHEMA_ID，再关联 DBA_ROLE_PRIVS 查看其角色层级深度。
