视图能通过AS重命名字段以适配新接口，但不改变底层表结构；旧代码若仍直查原表字段则报错，需同步修改SQL或用同名视图遮蔽（PG/SQL Server支持，MySQL不支持）。
视图能改字段名但不能改底层表结构
视图只是查询的封装，CREATE VIEW 里用 AS 给列起别名，只影响上层读取时的字段名显示，对原表 ALTER TABLE 没有任何作用。旧系统如果还有大量硬编码 SQL 直接引用原字段名（比如 SELECT user_name FROM t_user），光靠视图无法让这些语句自动生效——它们查的仍是原表，不是视图。
典型误用场景：开发以为建个视图把 user_name 改成 full_name，老代码就能无缝跑通。实际一执行就报错：column "full_name" does not exist，因为老代码没改成查视图。
- 视图适合新接入模块统一使用新字段语义，比如新写的报表服务只查
v_user_profile - 老代码迁移必须配合代码层搜索替换，或加兼容层（如创建同名视图覆盖原表名）
- PostgreSQL 支持
CREATE OR REPLACE VIEW，但 MySQL 8.0 之前不支持直接替换，需先DROP再CREATE
用视图模拟“字段重命名”并保持向后兼容
最实用的做法是：新建视图取和原表相同的名字，但定义里映射新字段名到旧字段。前提是数据库支持“同名视图遮蔽基表”（PostgreSQL 和 SQL Server 支持；MySQL 不支持——它会报 Table 'xxx' already exists）。
例如原表 t_user 有字段 usr_nm，你想对外暴露为 name：
CREATE VIEW t_user AS SELECT id, usr_nm AS name, created_at AS created_time FROM public.t_user_base;
这样，原来写 SELECT name FROM t_user 的新代码能跑通；但要注意：
- 该视图默认只读，
INSERT/UPDATE会失败（除非定义INSTEAD OF触发器，仅 PostgreSQL/SQL Server 支持） - MySQL 用户必须换方案：要么改应用代码，要么用
RENAME TABLE+ 别名表 + 同步双写过渡 - 索引不会继承，
WHERE name = ?无法走usr_nm上的索引，可能慢
视图字段名变更对 JOIN 和 ORM 的实际影响
很多 ORM（如 Django ORM、MyBatis）根据字段名生成属性，如果视图字段名变了但实体类没同步，运行时报错就是 AttributeError: 'User' object has no attribute 'full_name' 或 MyBatis 的 There is no getter for property named 'full_name'。
JOIN 场景更麻烦：假设 v_order 视图把 customer_id 改叫 client_id，而你写 JOIN v_user ON v_order.customer_id = v_user.id，就会提示字段不存在——因为 v_order 里已没有 customer_id 这个列名。
- 所有 JOIN 条件、
GROUP BY、ORDER BY都得按视图输出的字段名写，不是原表名 - Django 中需在
models.py里显式指定db_column='client_id'，否则迁移检测会失败 - 视图嵌套层级深了（如 A 视图 SELECT B 视图），字段来源难追溯，
EXPLAIN看执行计划时容易误判瓶颈位置
真正安全的字段重构路径
视图只是过渡手段，不是替代 ALTER TABLE RENAME COLUMN 的方案。PostgreSQL 9.6+、SQL Server、Oracle 都支持直接重命名字段；MySQL 8.0+ 也支持 RENAME COLUMN。优先走这条线：
- 先加新字段（
ADD COLUMN full_name VARCHAR(100)），用触发器或应用层双写保证数据一致 - 批量迁移历史数据（
UPDATE t_user SET full_name = user_name） - 灰度切应用读逻辑到新字段，确认无误后删旧字段（
DROP COLUMN user_name） - 视图只用于中间期兼容：比如建
v_user_legacy让老报表继续跑，新服务直连原表
绕开 DDL 直接依赖视图“假装改了字段”，会在排查慢查询、审计字段血缘、对接 BI 工具时反复踩坑——毕竟 pg_views 或 INFORMATION_SCHEMA.VIEWS 里的定义，和真实存储结构永远是两层皮。
