AUTHID CURRENT_USER不提升系统安全性，仅将权限主体从定义者切换为调用者；它通过限制执行权限范围避免隐性越权，但会增加共享池开销且要求明确管控调用者权限与schema上下文。
AUTHID CURRENT_USER 不等于“更安全”，而是权限边界更可控
直接说结论：AUTHID CURRENT_USER 本身不提升系统级安全性，它只是把执行时的权限主体从“定义者”切换为“调用者”。所谓“更安全”，实际是指：避免因过度依赖定义者高权限（如 SYS、SYSTEM）导致的越权操作风险。比如一个由 SYS 创建但标记为 AUTHID CURRENT_USER 的过程，即使被普通用户执行，也无法访问 DBA_* 视图——除非该用户自己有对应权限。
为什么 AUTHID DEFINER 容易引发隐性越权
定义者权限下，角色（ROLE）全部失效，所有权限必须显式授予对象级权限（如 GRANT SELECT ON dba_objects TO user_a）。但现实中，DBA 往往只给用户分配 DBA 角色，而没做对象级授权。这就造成一种假象：“用户能干所有事”，但一旦进到存储过程里，DBA 角色瞬间失效，过程直接报 ORA-00942: table or view does not exist 或 ORA-01031: insufficient privileges。
- 常见错误现象：
EXECUTE IMMEDIATE 'CREATE TABLE ...'在AUTHID DEFINER下失败，即使定义者有CREATE ANY TABLE - 根本原因：该权限来自角色，而角色在定义者模式下不可用
- 绕过方式不是加权限，而是改用
AUTHID CURRENT_USER——此时调用者自己的RESOURCE角色就生效了
AUTHID CURRENT_USER 对动态SQL和临时对象的关键影响
涉及 EXECUTE IMMEDIATE 的场景（建表、删表、改用户对象），AUTHID CURRENT_USER 是刚需。否则对象会创建在定义者 schema 下，且调用者无法访问；或因权限不足直接中断。
- 建全局临时表：
CREATE GLOBAL TEMPORARY TABLE t1(...)会落在调用者 schema，而非定义者 schema - 建普通表：
CREATE TABLE scott.emp_bak AS SELECT * FROM emp中的scott.emp_bak会被解析为调用者当前 schema 下的对象（除非显式写全scott.emp_bak） -
ALTER SESSION SET CURRENT_SCHEMA = xxx会影响AUTHID CURRENT_USER过程中未加 schema 前缀的对象解析，但不影响权限校验主体
容易被忽略的性能与共享池代价
很多人只看到权限好处，却忽略运行时开销：AUTHID CURRENT_USER 过程的 SQL 语句无法在共享池中跨用户复用。哪怕两个用户执行完全相同的 SELECT * FROM emp，Oracle 也会生成两条独立的游标。
- 表现：
V$SQL中出现大量重复 SQL_TEXT，但ADDRESS和CHILD_ADDRESS不同 - 影响：内存占用上升，硬解析增多，尤其在多租户或应用用户直连场景下明显
- 对策：仅在确实需要调用者权限的场景使用；避免在高频小过程上滥用
真正决定安全边界的，从来不是 AUTHID 关键字本身，而是你是否清楚每个过程最终以谁的身份、在哪个 schema、用哪些权限去碰数据或 DDL。混淆这两点，AUTHID CURRENT_USER 反而可能放大误操作范围。
