必须手动重建视图：先用SHOW CREATE VIEW（MySQL）、\d+ view_name（PG）或sys.dm_exec_describe_first_result_set（SQL Server）获取定义，再逐项比对当前基表字段名、表名及schema前缀是否一致，不匹配则重写SELECT列表并显式重建。
视图查不了，报 Unknown column 或 Table doesn't exist，不是缓存没清、权限不对，就是视图定义里写的字段或表名，跟当前库中实际存在的对象对不上——必须手动验证并重建，没有自动修复这回事。
怎么快速定位失效字段或表名
别靠肉眼扫 SHOW CREATE VIEW 输出，容易漏掉别名、大小写、子查询里的引用。直接查系统元数据，和当前基表结构逐列比对：
- MySQL：运行
SELECT * FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 'your_view_name'，看返回的列是否全在基表里存在；再用DESCRIBE base_table对照 - PostgreSQL：在
psql里执行\d+ your_view_name，记下“Column”列表；再\d base_table看基表当前字段，缺哪个就补哪个 - SQL Server：执行
SELECT * FROM sys.dm_exec_describe_first_result_set(N'SELECT TOP 0 * FROM your_view', NULL, 0)，重点看is_error = 1的行和error_message
重建视图时必须重写 SELECT 列表，不能只改表名
CREATE OR REPLACE VIEW 不是“智能同步”，它只是覆盖 SQL 文本，不会推导字段映射关系。原视图若写 SELECT id, name, phone FROM users，而 phone 已被删，你只把 users 改成 users_v2 还留着 phone，照样报错。
- 字段名不一致？必须显式重命名：
first_name || ' ' || last_name AS full_name（PG）或CONCAT(first_name, ' ', last_name) AS full_name（MySQL） - 类型变了（比如
INT→VARCHAR），且有WHERE age > 18？得加CAST(age AS INTEGER)，否则隐式转换可能失败 - MySQL 5.7 升 8.0 后启用了
ONLY_FULL_GROUP_BY，原SELECT id, name FROM t GROUP BY id必须补全所有非聚合字段，否则建不成功
为什么禁用 SELECT * 和嵌套视图
SELECT * 是最隐蔽的定时炸弹：底层表加字段，视图返回列数/顺序就变，JDBC 按索引取值（rs.getString(2)）会读错列；ORM 缓存元信息后更难察觉。
- 嵌套视图（如
v1 → v2 → v3）会让错误层层传递。v1 底层表一变，v3 报错信息可能只显示invalid column in v2，根本看不到源头 - 真要复用逻辑，优先用 CTE：
WITH base AS (SELECT ...) SELECT ... FROM base，执行时一次性展开，调试路径清晰 - 上线前必须跑一次
SELECT * FROM your_view LIMIT 1，比只验证 DDL 脚本更能早暴露列不匹配
真正麻烦的不是重建动作本身，而是字段语义漂移——比如 status 从字符串变成布尔，created_at 从 DATETIME 变成 TIMESTAMP WITH TIME ZONE。这类变化不会让视图立刻报错，但下游计算可能静默出错，必须人工审核每处表达式是否仍符合业务契约。
