用户a访问用户b的表需先授select权限并创建同义词：grant select on b.orders to a;再create synonym orders for b.orders;否则即使授权仍报ora-00942，因缺少select any table权限且同义词是必要简化手段。
如何让用户a访问用户b的表：先授select权限
跨模式查数据最基础的前提是权限。oracle默认禁止用户访问其他用户的对象，哪怕只是select。如果用户a想查用户b下的表orders，必须由b（或dba）显式授权：
GRANT SELECT ON B.orders TO A;- 若需批量授权，可用脚本生成语句，例如查出
B所有基表：SELECT 'GRANT SELECT ON B.' || table_name || ' TO A;' FROM dba_tables WHERE owner = 'B' AND nested = 'NO'; - 注意：
GRANT SELECT ON B.orders TO PUBLIC;虽可行，但存在安全风险，不建议生产环境使用
为什么直接写B.orders还是报ORA-00942：同义词不是可选，而是必要简化手段
即使已授权限，用户A执行SELECT * FROM B.orders;仍可能失败——这不是权限问题，而是当前用户A没有对B模式的SELECT ANY TABLE系统权限（该权限极危险，通常禁用）。此时必须依赖同义词：
- 在
A下创建私有同义词：CREATE SYNONYM orders FOR B.orders; - 之后
A就能直接写SELECT * FROM orders;，无需写模式前缀 - 若多个用户都要访问，
B可建公有同义词：CREATE PUBLIC SYNONYM orders FOR B.orders;，但需CREATE PUBLIC SYNONYM权限，且所有用户都能看到，命名冲突风险高
CREATE SYNONYM的常见陷阱：路径、大小写与刷新失效
同义词本身不存储数据，只是一层指向，但它的行为容易被低估：
- 目标对象改名或删掉后，同义词不会自动失效，查询时才报
ORA-00980: synonym translation is no longer valid - 创建时若目标表名含小写或特殊字符，必须用双引号：
CREATE SYNONYM my_tab FOR B."MyTable";，否则会转成大写导致找不到 - 同义词不能跨数据库（即不支持DB Link在同义词定义里嵌套DB Link），如
CREATE SYNONYM rmt_emp FOR remote_user.emp@dblink;语法合法，但调用时可能因权限上下文失败——推荐把DB Link访问封装进视图，再为视图建同义词
性能与维护提醒：同义词不改变执行计划，但影响可读性与变更跟踪
同义词对SQL执行计划无任何影响，CBO仍按实际对象优化。但它会让对象来源变得隐蔽：
-
SELECT * FROM orders;看起来像本地表，实则指向B.orders，排查慢SQL时容易误判范围 - 数据字典中查同义词需用
dba_synonyms或all_synonyms，而不是dba_tables；注意owner字段指同义词所属用户，table_owner才指源对象用户 - 应用升级需同步检查同义词依赖，尤其当源表字段变更、约束调整时，同义词本身不会报错，但上层应用可能崩在运行时
跨模式访问真正麻烦的从来不是语法，而是权限链路是否闭环、同义词是否及时同步、以及开发和DBA之间对“这个表到底在谁那儿”的认知是否一致。
