用视图拦截查询，将失效字段映射为NULL或默认值，并显式声明类型以匹配原字段；支持多别名需在SELECT中同时列出；严禁在视图中变更基础类型或添加不可下推计算。
旧表字段已删但应用还在查，怎么让 SELECT 不报错？
直接加回原字段？不行——旧逻辑可能已废弃，且数据库 schema 混乱。正确做法是用视图拦截查询，把失效字段映射成常量或空值。比如原表 users 删除了 last_login_ip，但老应用仍执行 SELECT id, last_login_ip FROM users，这时建视图覆盖原表名（需先重命名原表）：
ALTER TABLE users RENAME TO users_legacy; CREATE VIEW users AS SELECT id, NULL::inet AS last_login_ip, created_at, status FROM users_legacy;
注意：PostgreSQL 中 NULL::inet 显式指定类型，避免视图列类型推导为 unknown 导致下游 CAST 失败；MySQL 需用 CAST(NULL AS CHAR) 等匹配原字段类型。
应用混用新旧字段名，视图里怎么同时支持 login_ip 和 last_login_ip？
不能只 alias 一个字段——要让两个名字都可查，且语义一致。最稳的方式是显式列出所有字段，对别名做等价映射：
CREATE VIEW users AS
SELECT
id,
login_ip AS last_login_ip,
login_ip AS login_ip,
created_at,
updated_at
FROM users_legacy;关键点：
- 两个字段名必须在
SELECT列表中都出现，顺序无关，但名称必须字面匹配 - 如果
login_ip在源表中也不存在，就统一返回NULL或默认值，别依赖函数动态生成（会拖慢全表扫描） - SQL Server 用户注意：
AS别名不能和源字段同名再出现第二次，得用子查询包一层
视图里改字段类型引发 JDBC 报错 Bad value for type long 怎么办？
这是典型类型不匹配：应用代码用 ResultSet.getLong("user_id")，但视图里该字段被写成 CAST(id AS TEXT)。解决路径很明确：
- 优先还原原始类型：查
users_legacy的id实际类型（pg_typeof()或DESCRIBE），视图中严格保持一致 - 若必须转类型（如把整数 ID 转成带前缀字符串），不要在视图里做，改由应用层处理；否则 JDBC 驱动解析失败是必然的
- MySQL 8.0+ 支持
CREATE VIEW ... WITH CHECK OPTION，但类型兼容性不在此控制范围内，别误以为能兜底
上线后发现视图性能暴跌，EXPLAIN 显示全表扫描 + 多层嵌套
常见诱因是视图嵌套过深或用了不可下推的表达式。比如：
CREATE VIEW users_v2 AS SELECT *, md5(email) AS email_hash FROM users_v1; -- users_v1 本身已是视图
此时 PostgreSQL 可能无法将 WHERE email = 'x' 下推到最底层表。对策只有两条：
- 扁平化：把
users_v1的定义内联进users_v2，删掉中间视图 - 禁用非必要计算：视图里别放
md5()、now()、子查询，这些会让优化器放弃下推 - 给视图加注释说明“此视图仅用于兼容，禁止在 WHERE 中引用计算列”，靠协作而非技术强制
最麻烦的是 Oracle —— 它的视图合并（view merging）规则极多，ROWNUM、外连接、聚合哪怕出现一次，整个视图就会固化为物化结果，延迟和内存开销陡增。这种情况，不如直接上物化视图或反范式冗余字段。
