视图中用AS重命名列是唯一可靠方式，因SQL标准无独立重命名语法，ALTER TABLE仅改物理结构；必须显式写AS，含特殊字符时需加引号，禁止SELECT*，JOIN需逐列AS，应用层须用列名而非位置访问，重建视图应使用CREATE OR REPLACE VIEW。
视图里用 AS 重命名列是唯一可靠方式
SQL 标准里没有“重命名列”的独立语法，ALTER TABLE ... RENAME COLUMN 是修改物理表结构，不能用于解耦业务逻辑。视图才是正确出口——它不改底层表，只在查询层做别名映射。
常见错误是试图在视图定义里漏掉 AS，比如写 SELECT user_id id FROM users，在 PostgreSQL 里能跑，但 MySQL 8.0+ 会报 ERROR 1054 (42S22): Unknown column 'id' in 'field list'，因为没显式声明别名。
- 必须写成
SELECT user_id AS id FROM users - 别名含空格或特殊字符时，要用双引号（PostgreSQL）或反引号（MySQL），如
SELECT name AS "full name" - 多个列重命名要逐个写
AS，不能批量操作
视图列名冲突时，SELECT * 会直接失效
如果底层表字段名重复（比如两个 JOIN 表都有 id），又用了 SELECT *，视图创建会失败，或后续查询报 ERROR 1052 (23000): Column 'id' in field list is ambiguous。
这不是语法问题，是 SQL 引擎无法推导出明确的列标识。业务代码一旦依赖这种模糊写法，上线后就容易崩。
- 禁止在视图中使用
SELECT *，哪怕只是临时调试 - JOIN 多表时，所有列必须显式写出并带
AS，例如u.id AS user_id, o.id AS order_id - 已有视图出错，先用
DESCRIBE view_name或\d view_name查列名，再对应修正
应用层读取列名时，别硬编码字符串
很多后端代码（尤其是 Python 的 cursor.fetchall() 或 Java 的 ResultSetMetaData）默认按位置取值。但如果视图列顺序变了，或者中间加了新列，硬编码索引（如 row[2]）就会取错字段。
更隐蔽的问题是：不同数据库对视图元信息的暴露程度不同。SQLite 返回的是原始列名，而 PostgreSQL 可能返回 AS 后的名字，但某些驱动版本会忽略它。
- 优先用列名访问，如 Python 的
row['user_name']（需开启row_factory） - Java 里用
rs.getString("user_name")而非rs.getString(3) - 生成 ORM 模型时，确保工具解析的是视图的最终列名，不是底层表字段名
CREATE OR REPLACE VIEW 是安全更新的前提
视图本身不可 ALTER COLUMN，想改列名只能重建。直接 DROP VIEW + CREATE VIEW 有风险：并发查询可能瞬间报 ERROR 1146 (42S02): Table doesn't exist。
CREATE OR REPLACE VIEW 是原子操作，在大多数主流数据库（PostgreSQL、MySQL 5.7+、SQL Server）中能保证切换过程无中断。但注意：Oracle 不支持 OR REPLACE，得用 CREATE OR REPLACE FORCE VIEW，且需额外权限。
- MySQL 5.6 及更早版本不支持
OR REPLACE，必须手动处理依赖锁 - 重建前先验证新定义是否能执行，避免
CREATE OR REPLACE成功但后续查询失败 - 生产环境变更前，用
EXPLAIN确认执行计划没退化——视图重命名本身不影响性能，但改写逻辑可能引入隐式转换
真正麻烦的不是怎么写 AS，而是当几十个服务都依赖同一个视图列名时，改一个名字要全链路对齐。列名一旦对外暴露，就不再是数据库的事了。
