视图查询报错“Unknown column”或“Table doesn't exist”源于底层表结构变更而视图未同步更新；MySQL和PostgreSQL均不校验依赖对象实时状态，需手动重建视图并显式声明字段。
视图查询报错 Unknown column 或 Table doesn't exist
底层表字段被删、重命名，或表被 DROP，视图不会自动失效，但下次查询就会爆这个错。MySQL 和 PostgreSQL 都这样——视图只是保存了 SELECT 语句文本，不校验依赖对象的实时状态。
- 建视图时加
WITH CHECK OPTION（MySQL）或用SECURITY DEFINER（PostgreSQL）都救不了字段缺失问题，它们管权限和插入校验，不管列是否存在 - 上线前必须跑一次
SELECT * FROM <view_name> LIMIT 1，不能只靠 DDL 脚本通过就认为 OK - CI/CD 流程里建议在迁移表结构后，自动执行
SELECT COUNT(*) FROM <view_name>，比EXPLAIN更早暴露列不匹配
用 CREATE OR REPLACE VIEW 重建视图是否安全
安全，但有陷阱：它不会帮你补字段别名、改数据类型、处理表达式变更。比如原视图里写 price * 1.1 AS final_price，你把底层 price 改成 unit_price，直接 CREATE OR REPLACE 会继续报 Unknown column 'price'。
- 必须同步更新视图定义里的所有引用字段，不能只改表结构
- PostgreSQL 中
CREATE OR REPLACE VIEW允许改返回列数，MySQL 8.0+ 才支持；旧版 MySQL 必须先DROP再CREATE，注意权限和依赖视图的锁问题 - 如果视图被其他视图引用（嵌套），重建顺序很重要：得从最底层视图开始往上刷，否则中间层会因依赖失效而创建失败
视图里用 * 是不是省事又灵活
不是。用 SELECT * 建视图等于埋雷：一旦底层表加字段，视图返回列顺序和数量就变了，上层应用按位置取值（比如 JDBC 的 rs.getString(2)）会读错字段；更糟的是，某些 ORM 框架缓存了列元信息，重启前一直用旧结构解析结果。
- 始终显式写出字段名，哪怕多写十行。需要扩展时，手动追加新字段并设默认值，比如
'N/A'::TEXT AS category_name - 想模拟“自动适配”，可用生成脚本（如 pg_get_viewdef() + 正则提取字段），但不能替代人工审核——类型隐式转换可能出错
-
INFORMATION_SCHEMA.VIEWS可查视图定义，但不能反推它依赖哪些列；真要追踪影响面，得结合pg_depend（PG）或mysql.proc（MySQL）分析依赖树
物化视图能缓解结构变更冲击吗
不能。PostgreSQL 的物化视图（MATERIALIZED VIEW）本质是快照，刷新时才重新执行查询，但它依然依赖底层表结构。如果刷新前表已被改，REFRESH MATERIALIZED VIEW 直接失败，错误信息和普通视图一样是 column does not exist。
- 物化视图适合解决性能问题，不是解耦手段；它让结构变更的影响从“查询时暴露”推迟到“刷新时暴露”，反而更难及时发现
- 若真要用，务必把
REFRESH步骤纳入表结构迁移的原子事务中——先改表，再刷新，失败则回滚整个批次 - SQL Server 的索引视图（Indexed View）对底层变更更敏感，连表加个非空约束都可能导致索引视图失效，需格外留意
SCHEMABINDING约束是否仍满足
最麻烦的不是改字段，是改字段类型还带隐式转换——比如把 VARCHAR(50) 改成 TEXT，视图里用 UPPER(col) 在某些版本会触发 collation 冲突，报错不明显，只在特定 WHERE 条件下才崩。
