视图中同名字段必须显式重命名，因SQL标准要求视图列名唯一，否则建视图直接失败（如ORA-00957或ERROR 1060）；必须用AS为所有冲突字段指定语义清晰的别名（如user_id、order_id），禁止SELECT *，且每层嵌套均需独立处理。
视图中同名字段必须显式重命名
SQL 视图的列名必须唯一，当 SELECT 中出现两个表都有的字段（比如都叫 id 或 name），数据库会直接报错，常见错误是：ORA-00957: duplicate column name（Oracle）或 ERROR 1060 (42S21): Duplicate column name（MySQL）。这不是警告，是硬性限制——视图定义不通过，根本建不出来。
解决方式只有一条：所有可能冲突的字段，必须用 AS 显式指定别名。不能依赖“先出现的保留原名、后出现的自动忽略”这类幻想逻辑。
- 哪怕只有一处同名，整个视图都会失败；不要试图靠顺序“蒙混过关”
-
SELECT *在多表 JOIN 视图中是高危操作，极易触发冲突，应绝对避免 - 别名建议带表前缀，例如
t1.id AS user_id、t2.id AS order_id，既消歧义又便于后续维护
JOIN 场景下字段冲突的典型写法
以 MySQL 或 PostgreSQL 为例，假设 users 和 orders 表都有 id、created_at 字段：
CREATE VIEW user_order_summary AS SELECT u.id AS user_id, u.name AS user_name, u.created_at AS user_created_at, o.id AS order_id, o.status AS order_status, o.created_at AS order_created_at FROM users u JOIN orders o ON u.id = o.user_id;
注意：u.created_at 和 o.created_at 必须分别重命名，哪怕你当前只关心其中一个，也得给另一个起别名——否则语法校验就过不去。
- 别用
AS created_at这种无前缀别名，后续查询时根本分不清来源 - 如果某字段确实不需要，就别 SELECT 它，而不是留着让它冲突
- PostgreSQL 对大小写更敏感，别名里混用大小写（如
User_ID）可能在某些客户端引发意外解析问题
不同数据库对字段重复的容忍度差异
绝大多数主流数据库（MySQL、PostgreSQL、SQL Server、Oracle）都严格执行“视图列名唯一”，但细节有差别：
- SQLite 允许同名列出现在
SELECT列表中，但实际只取第一个值，其余被静默丢弃——这属于危险的“伪成功”，极易导致业务逻辑出错，不建议依赖 - SQL Server 在视图定义阶段就拒绝重复列名，错误信息明确："
The column 'xxx' was specified multiple times for 'yyy'" - Oracle 要求不仅列名唯一，还要求别名符合标识符规则（不能以数字开头、不能含空格等），
AS "user id"会失败，得写成AS user_id
用子查询绕过冲突？没必要且更难维护
有人想用嵌套子查询先处理一张表，再 JOIN，以为能“隔离”字段名。例如：
SELECT u.*, o.* FROM (SELECT id AS user_id, name FROM users) u JOIN (SELECT id AS order_id, user_id FROM orders) o ON u.user_id = o.user_id;
这看似绕开了，但问题没解决：u.* 和 o.* 展开后仍可能产生同名列（比如两张子查询都输出了 user_id），而且可读性差、执行计划更难优化。
- 子查询只是临时封装，不改变最终 SELECT 列的命名约束
- 视图本质是保存的 SELECT 语句，优化器不会因为你多套一层就放宽校验
- 真正省事的做法，是老老实实给每个需暴露的字段配清晰别名
最常被忽略的一点：视图一旦创建成功，后续修改表结构（比如给源表加了个新字段，恰好和另一张表已有字段同名），可能导致原本可用的视图突然失效——因为 CREATE OR REPLACE VIEW 会重新解析整个 SELECT，冲突重现。所以别只盯着建的时候，要持续关注字段命名的稳定性。
