必须显式列出字段，禁用SELECT ：因字段废弃时视图需模拟旧字段以保障兼容，而SELECT 在底层删字段后会导致查询报错或错位，且无法兜底废弃字段。
视图是字段废弃时最可控的向后兼容手段，它不改表、不锁表、不中断写入，只在查询层把旧字段“模拟”出来；但必须显式声明所有字段，禁用 SELECT *，否则字段删掉后视图直接失效。
CREATE VIEW 里为什么必须显式列出字段而不是用 SELECT *
用 SELECT * 看似省事，实则埋雷：一旦底层表删掉 user_name 字段，视图创建会成功，但后续任何 SELECT user_name FROM users_legacy 都报错 column "user_name" does not exist。更危险的是 MySQL 可能静默跳过缺失列，导致应用按位置取值时错位。
- 所有字段必须手写，包括新增字段（避免漏加）和废弃字段（用表达式兜底）
- 字段顺序要和旧系统预期一致，尤其影响
INSERT INTO t1 SELECT * FROM v1类语句 - PostgreSQL 和 SQL Server 要求每个字段带
AS别名，MySQL 8.0+ 推荐也写，避免歧义
废弃字段是改名、拆分还是彻底删除？写法完全不同
字段废弃不是单一动作，得先判断类型再选映射策略：
- 纯改名（
user_name → full_name）：full_name AS user_name - 拆分（
user_name拆成first_name+last_name）：COALESCE(first_name || ' ' || last_name, user_name) AS user_name，COALESCE覆盖双写过渡期空值 - 彻底删除且无替代（如移除冗余
temp_flag）：NULL::BOOLEAN AS temp_flag（PostgreSQL）或CAST(NULL AS TINYINT) AS temp_flag（SQL Server），保持列存在但值恒为 NULL
注意字符串拼接符差异：|| 适用于 PostgreSQL/SQLite，MySQL 用 CONCAT(first_name, ' ', last_name)，SQL Server 用 first_name + ' ' + last_name。
视图里写业务逻辑（比如 CASE WHEN）会带来什么隐性成本
把状态映射写进视图看似方便，实则让后期清理变成灾难：比如 CASE WHEN status = 'A' THEN 'active' ELSE 'inactive'，等业务统一改成 'enabled'/'disabled' 时，你得逐个找视图改，还可能漏掉某个 BI 报表专用视图。
- 视图只做字段级翻译，不做语义级转换；状态映射、枚举标准化应由应用或中间层统一处理
- 含
CASE、COALESCE、函数调用的视图，MySQL 优化器可能放弃索引，导致 JOIN 性能骤降 - 如果必须兜底空值，优先用
COALESCE(new_col, old_col)，而不是COALESCE(new_col, 'default')—— 后者掩盖了数据迁移不完整的问题
上线后怎么安全下线这个视图
不能等所有调用方都改完才删视图，得主动收敛。最有效的方式是在视图定义里加可监控的“退役信号”：
- PostgreSQL 可在视图里加
pg_notify('view_deprecated', 'users_legacy')，配合监听端收集调用量 - 通用做法是加一个临时字段：
'[DEPRECATED] use full_name instead'::TEXT AS _deprecated_hint，让日志或 ORM 映射时暴露警告 - 定期查依赖：
SELECT * FROM pg_depend WHERE refobjid = 'users_legacy'::regclass（PostgreSQL），确认还有谁在用 - 真正删视图前，先
REVOKE SELECT ON users_legacy FROM PUBLIC，观察是否有权限拒绝日志爆出残留调用
最容易被忽略的是 Shell 脚本或 BI 工具里的位置引用（比如 cut -f3 或 [Column3]），它们不认字段名，只认顺序 —— 这类隐式依赖不会出现在任何依赖分析里，只能靠灰度切流时的日志告警发现。
