视图删除底层列后首次查询即报错，因其创建时已固化列元数据，不监听基表变更；sp_refreshview无法修复缺失列，仅重绑定现有引用；硬编码字段名导致列错位比报错更危险。
删除底层列后，视图不会自动同步更新结构，是因为视图只保存创建时解析出的列元数据快照，不监听、不校验基表结构变更——它根本“不知道”列被删了，直到你查它时才暴露问题。
SELECT * 视图查不到新字段，也报不出删字段的错？
这是典型误解。用 SELECT * 创建的视图，在底层列被删除后，首次查询就会直接报错，比如：
-
Unknown column 'phone' in 'field list'（MySQL） -
Invalid column name 'phone'（SQL Server） -
column "phone" does not exist（PostgreSQL）
错误不是延迟出现的，而是执行时实时解析失败。视图定义里虽写着 *，但数据库在 CREATE VIEW 阶段已把当时展开的列名、类型、顺序固化进系统表（如 sys.columns 或 pg_attribute），后续删列不会触发任何自动修正。
sp_refreshview 能救被删列的视图吗？
不能。在 SQL Server 中，sp_refreshview 的作用是重绑定现有引用，不是补漏或容错：
- 它会尝试重新解析视图定义中所有对象，如果发现某列已不存在，立即报错并中断，不会跳过或忽略
- 执行
EXEC sp_refreshview 'my_view'后仍报Invalid column name，说明该列确实没了，必须人工修改视图定义 - 对含
WITH SCHEMABINDING的视图，刷新前还必须确保所有被引用列仍存在且类型兼容，否则直接失败
为什么不能像 ALTER TABLE 那样自动适配？
因为视图不是“活连接”，而是静态语句封装：
- 数据库不维护视图与基表之间的运行时依赖关系；它不轮询、不监听 DDL 变更
-
ALTER TABLE ... DROP COLUMN是原子操作，不触发任何回调或事件通知给视图 - MySQL 和 PostgreSQL 根本没有
sp_refreshview这类机制——它们每次查询都从头解析视图文本，所以删列后第一次查就崩，没“缓存延迟”可言 - 即使你用
CREATE OR REPLACE VIEW（MySQL 8.0+/PG），只要定义里还引用已删列，照样报错，不会帮你自动剔除
真正危险的不是报错，而是没报错：当视图里硬写了字段名（如 SELECT id, name, phone），而 phone 被删后，你可能误以为视图“还能用”，直到某天应用取第3列时拿到的是 email 值——列错位比报错更难排查。
