应先确认数据库和schema是否正确，再检查表名拼写与大小写、权限及视图依赖。常见原因包括连错库、未指定schema、表名含特殊字符或保留字、权限不足、视图引用失效等。
确认当前数据库和schema是否正确
很多“表不存在”错误其实是因为连错了库，或者没指定schema。MySQL默认不区分大小写但Linux下表名实际区分；PostgreSQL和Oracle则严格区分schema，SELECT * FROM users可能查的是public.users，而你的表其实在app_schema.users里。
- 先执行
SELECT current_database()（PostgreSQL）或SELECT DATABASE()（MySQL）确认当前库名 - 查表归属：PostgreSQL用
SELECT table_schema, table_name FROM information_schema.tables WHERE table_name = 'xxx'；MySQL用SHOW TABLES FROM xxx_db LIKE 'xxx' - 显式带上schema：把
SELECT * FROM users改成SELECT * FROM app_schema.users
检查表名拼写、大小写和特殊字符
表名里有下划线、数字开头、或用了关键字（比如叫order、user），没加引号就会报错。PostgreSQL强制小写未加引号的标识符，SQL Server对大小写敏感取决于collation，Oracle默认大写未加引号的表名。
- 用
SELECT table_name FROM information_schema.tables实际查出表名，复制粘贴，避免手误 - 含特殊字符或大小写混用时，必须用双引号（PostgreSQL/Oracle）或反引号（MySQL）：写成
"MyTable"或`my-table`，不能只靠记忆 - 避免用保留字作表名；如果已用，每次查询都得加引号，否则
SELECT * FROM order直接语法错误
权限不足导致“表不存在”的假象
某些数据库（尤其是PostgreSQL和SQL Server）在用户没有USAGE权限到schema、或没有SELECT权限到表时，会统一报“relation does not exist”或“invalid object name”，而不是明确说“permission denied”。这容易误导排查方向。
- 用管理员账号执行
SELECT has_table_privilege('username', 'schema.table', 'SELECT')（PostgreSQL）验证权限 - 检查schema级权限：
SELECT has_schema_privilege('username', 'schema_name', 'USAGE') - MySQL中对应检查
SHOW GRANTS FOR 'user'@'host'，确认包含类似GRANT SELECT ON db_name.table_name TO ...
视图依赖的对象被删或改名了
查询视图时报“表不存在”，但视图本身存在——说明视图定义里引用的某张底层表已被删除、重命名，或移走了schema。视图不会自动失效，只有真正查询时才报错。
- 查视图定义：
SELECT definition FROM pg_views WHERE viewname = 'xxx'（PostgreSQL）；MySQL用SHOW CREATE VIEW xxx - 逐个核对定义中出现的每张表是否存在、是否在正确schema下
- 注意物化视图或带函数的视图可能隐式依赖系统表或扩展，升级数据库后这类依赖容易断链
实际遇到时，先跑一遍schema确认和表名校验，再看权限，最后查视图定义——顺序错了容易在权限上浪费半小时，结果发现只是表在另一个库。跨环境迁移（开发→测试→生产）时，schema名不一致是最常见的隐形坑。
