alter session set current_schema仅影响未加schema前缀的对象解析，不改变权限上下文，权限校验仍基于原始登录用户；正确用途是简化同名对象引用，但需配合authid definer，若需切换执行权限主体则应使用authid current_user并提前授对象权限。
ALTER SESSION SET CURRENT_SCHEMA 不会改变权限上下文
很多人以为执行 ALTER SESSION SET CURRENT_SCHEMA = other_user 就能让当前会话“变成”那个用户，可以绕过对象权限检查——这是错的。它只影响未加 schema 前缀的对象解析（比如直接写 SELECT * FROM emp 时默认查 other_user.emp），但所有权限校验仍基于**原始登录用户**。你还是得有 SELECT ON other_user.emp 才能查，否则报 ORA-00942 或 PLS-00201。
重置 CURRENT_SCHEMA 的正确用途是简化同名对象引用
典型场景：多个 schema 都有 orders 表，你在包里写一堆不带前缀的 SQL，又不想硬编码 schema 名。这时可在过程开头设一次：ALTER SESSION SET CURRENT_SCHEMA = app_data;，后续 INSERT INTO orders 就自动指向 app_data.orders。但注意：
- 该语句在存储过程中**必须用
EXECUTE IMMEDIATE包裹**，不能直接写；否则编译报错PLS-00103 - 它只对当前会话生效，不会影响其他会话，也不持久化
- 设完后
CURRENT_SCHEMA变了，但USER、SYS_CONTEXT('USERENV', 'SESSION_USER')还是原始登录用户，这点常被忽略
想“切换身份”？别用 CURRENT_SCHEMA，改用 AUTHID CURRENT_USER
如果真需要以目标 schema 的权限运行代码（比如让 scott 用户调用过程时，过程里查 hr.employees 不报错），唯一办法是把过程定义为 AUTHID CURRENT_USER，并确保调用者本身已被授予对应对象权限：
- 过程头必须显式声明：
CREATE OR REPLACE PROCEDURE my_proc AUTHID CURRENT_USER AS ... - 调用者（如
scott）需提前有SELECT ON hr.employees，不是靠过程所属用户（如hr）去授权 -
CURRENT_SCHEMA在这种模式下依然只是解析辅助，不参与权限判定
容易踩的坑：混用 AUTHID DEFINER 和 CURRENT_SCHEMA
默认 AUTHID DEFINER 下，过程以创建者身份运行，此时设 CURRENT_SCHEMA 完全多余——对象解析和权限检查都走创建者视角。常见错误链路：
- 过程用
AUTHID DEFINER写在hr下 - 里面执行
EXECUTE IMMEDIATE 'ALTER SESSION SET CURRENT_SCHEMA = scott' - 再查
SELECT * FROM emp→ 实际查的是hr.emp（因为权限上下文是hr，解析也优先找自己 schema） - 你以为切到了
scott，其实什么都没变
真正要安全“重置”会话的 schema 上下文，核心不是命令怎么写，而是先想清楚：你要的是简化对象引用（用 CURRENT_SCHEMA + AUTHID DEFINER），还是切换执行权限主体（用 AUTHID CURRENT_USER + 提前授对象权限）。两者逻辑互斥，混用必出问题。
