报Unknown column或Table doesn't exist是底层表字段被删/重命名、表被DROP/重命名或移入其他schema的直接信号；数据库不校验依赖实时性，只执行创建时写死的SQL文本。
视图查询报错不是因为“视图坏了”，而是它展开后引用的字段或表根本不存在了——MySQL、PostgreSQL、SQL Server 都不校验依赖实时性，只认创建时写死的 SQL 文本。
报 Unknown column 或 Table doesn't exist 是什么信号
这俩错误直接对应两种物理变更：
-
Unknown column 'dept_name'→ 底层表字段被删、重命名（比如改成了department_name） -
Table 'mydb.sys_user' doesn't exist→ 表被 DROP、重命名（sys_user→sys_users）、或移入其他 schema（比如从dbo搬到staging）
注意：这不是缓存没清、也不是权限问题。你查 sys.views 或 information_schema.VIEWS 会发现视图还在，但一执行就崩——因为数据库每次查询都重新解析那串硬编码的 SQL。
sp_refreshview 为什么执行成功却查不了
它只更新列元数据（比如字段名、是否可空、system_type_id），完全不碰 FROM 子句里的表名、schema 前缀、JOIN 条件或函数调用。
- 基表从
users改成app_users？sp_refreshview无感 - 视图里写了
SELECT *，底层表删了一列？它不会帮你删掉返回的 NULL 列 - 你连的是
test库，但视图定义里是prod.dbo.orders？它照样返回“成功”
SQL Server 中真正有效的验证方式是：sys.dm_exec_describe_first_result_set(N'SELECT * FROM your_view') —— 它会立刻报错，而不是等你 SELECT 时才暴露问题。
重建视图必须显式写字段，不能靠 SELECT *
用 CREATE OR REPLACE VIEW 或 DROP + CREATE 时，如果原定义含 SELECT *，重建后依然会崩：
- 底层表加字段 → 视图返回列数/顺序变，JDBC 按索引取值（
rs.getString(2)）直接读错 - 底层表删字段 →
SELECT *立刻报Unknown column - 字段类型不兼容（如
INT改VARCHAR），视图里又做了数学运算？表达式得重写才能避溢出
正确做法是逐列映射：first_name || ' ' || last_name AS full_name（PG）、CONCAT(first_name, ' ', last_name) AS full_name（MySQL）、COALESCE(email, '') AS email 补空、CASE WHEN status = 'active' THEN 1 ELSE 0 END AS is_enabled 对齐语义。
嵌套视图和跨 schema 引用最容易漏检
视图 A 引用了视图 B，B 又依赖表 C —— 如果 C 被改名，A 查起来报错可能显示 relation "v_order_items" does not exist，但你在 A 的定义里根本找不到这个名。这时候必须顺藤摸瓜：
- SQL Server：查
sys.sql_expression_dependencies，用referencing_id = OBJECT_ID('A')找出所有真实依赖项 - PostgreSQL：用
pg_get_viewdef('B')展开 B 的定义，再检查它引用的表是否存在 - MySQL：解析
information_schema.VIEWS.VIEW_DEFINITION字段，手动比对每张表和字段
跨 schema 引用（如 core.users）更要确认目标 schema 是否存在、当前用户是否有权限访问——哪怕表名没错，schema 缺失也会导致 Invalid object name。
