ORA-00942错误主因是schema不匹配、表名大小写敏感未正确引用或用户缺乏对象权限；需依次验证默认schema、真实表名（含引号）、SELECT权限及同义词有效性。
ora-00942 不是表真没了，八成是你没说清“谁的表”——schema、权限、大小写，三者漏一个就报这个错。
查当前 session 默认 schema 是什么
Oracle 查表时，默认只在你当前 session 的 schema 下找，不会自动跨 schema 搜索。比如你用 APP_USER 登录，却执行 SELECT * FROM emp，它实际查的是 APP_USER.emp，哪怕 SCOTT.emp 真存在，也报 ORA-00942。
立刻验证当前默认 schema：
SELECT SYS_CONTEXT('USERENV', 'CURRENT_SCHEMA') FROM DUAL;再确认目标表真实归属：
SELECT OWNER FROM ALL_TABLES WHERE TABLE_NAME = 'EMP';
- 如果返回
SCOTT，但上一步是APP_USER，那就得切 schema：ALTER SESSION SET CURRENT_SCHEMA = SCOTT - 该命令只对当前连接生效；断开重连就失效，别指望它“永久设置”
- 生产环境脚本里，更稳妥的做法是显式写全名：
SELECT * FROM SCOTT.emp
表名带双引号？大小写必须完全匹配
建表时用了双引号（如 CREATE TABLE "QueryHistory"），那 Oracle 就按你写的大小写存，之后每次引用都得加引号、且大小写一模一样。
错误示例：
-
SELECT * FROM QueryHistory→ Oracle 当作QUERYHISTORY查，找不到 -
SELECT * FROM "queryhistory"→ 大小写不一致，照样报 ORA-00942
查真实表名最可靠方式：
SELECT TABLE_NAME FROM ALL_TABLES WHERE UPPER(TABLE_NAME) = 'QUERYHISTORY';
如果结果是 "QueryHistory"（带引号），那就必须写成：SELECT * FROM "QueryHistory"
建议：除非业务强要求，否则建表别用双引号，统一用大写命名，省去所有大小写歧义。
权限缺失也会伪装成“表不存在”
Oracle 的安全策略是“不暴露对象是否存在”，所以即使表真实存在、schema 也对，只要没 SELECT 权限，照样报 ORA-00942，而不是 ORA-01031 权限不足。
检查权限分两步：
- 是否被直接授权：
SELECT PRIVILEGE FROM USER_TAB_PRIVS WHERE TABLE_NAME = 'EMP' AND GRANTEE = 'APP_USER' - 是否通过角色获得：
SELECT * FROM SESSION_ROLES，再确认该角色是否真有SELECT权限（注意：PL/SQL 中角色权限默认不生效，需SET ROLE）
缺权限就让 DBA 执行：
GRANT SELECT ON SCOTT.emp TO APP_USER;
同理，如果 Hibernate 用 @GeneratedValue(strategy = GenerationType.SEQUENCE) 报 ORA-00942，大概率是缺序列的 SELECT 权限，不是表权限：GRANT SELECT ON SCOTT.my_seq TO APP_USER
用同义词或数据库链接时特别容易掉坑
同义词失效、指向的原对象被删、或权限没同步，都会导致 ORA-00942。查同义词是否有效：
SELECT * FROM USER_SYNONYMS WHERE SYNONYM_NAME = 'EMP';
如果查到，再看 TABLE_OWNER 和 TABLE_NAME 是否对应真实存在的对象；如果查不到，说明当前用户下没建 private 同义词，也没 public 同义词可用。
用数据库链接（@db_link）时，Oracle 19c 起更严格：不仅目标库要授权，查询语句里也必须带 schema 前缀：
- 错：
SELECT * FROM emp@my_db_link - 对：
SELECT * FROM SCOTT.emp@my_db_link
授权也要带 schema：GRANT SELECT ON SCOTT.emp TO APP_USER，光授 emp 不行。
最容易被忽略的是：Navicat 里设了 Current Schema，但只对新建查询窗口生效；切换标签页或重启后就得重设，或者干脆在连接配置的「高级」里固化该值。
