<p>视图中同名字段导致 SELECT * 失败，必须显式列出字段并为冲突字段指定语义清晰的别名（如 user_id、order_id），且每层嵌套视图均需独立处理命名，不可依赖下层别名穿透。</p>
视图中同名字段导致 SELECT * 失败
直接 SELECT * 创建视图时，如果多个表都有 id、name 或 created_at 这类通用字段，数据库会报错：ORA-00957: duplicate column name（Oracle）或 ERROR 1060 (42S21): Duplicate column name（MySQL）。这不是语法错误，而是列名必须唯一的基本约束。
解决方法只有一条：显式列出所有字段，并为冲突字段指定别名。
- 绝对不要在视图定义里写
SELECT *，哪怕临时调试也不行 - 用
table1.id AS user_id、table2.id AS order_id这种方式消除歧义 - 别名要语义清晰，避免用
id1、id2这类无意义命名
JOIN 场景下字段别名的优先级规则
当使用 LEFT JOIN users u ON u.id = orders.user_id 时，u.id 和 orders.id 都存在，但数据库不会自动“猜”你要哪个。字段别名在视图定义中是强制生效的，且优先级高于原始列名。
注意两点：
- 别名一旦定义，外部查询再引用该视图时，只能用别名（如
user_id），不能用原始名（如u.id） - 如果漏写别名，而两个表恰好有同名列，建视图直接失败，不会默认取左表或右表的值
- PostgreSQL 对别名大小写更敏感，建议统一用小写加下划线（
user_created_at）
视图字段名冲突对下游应用的影响
很多 ORM（比如 Django 的 Model.objects.raw() 或 SQLAlchemy 的 text() 查询）依赖视图返回的列名做映射。如果视图字段名重复或含特殊字符，会导致 KeyError 或字段值错位。
实操建议：
- 用
DESCRIBE view_name（MySQL）或\d view_name（PostgreSQL）检查视图结构，确认每列名称唯一且可读 - 避免在别名中使用空格、连字符或中文；用下划线分隔，如
payment_status而非payment-status - 如果业务上真需要保留原始字段名（比如对接旧系统），可在视图里保留一个，其余用
NULL AS xxx占位，但需文档注明
嵌套视图中同名字段的传递风险
当你基于已有视图再创建新视图（比如 CREATE VIEW v2 AS SELECT * FROM v1 JOIN ...），v1 中已重命名的字段如果在 v2 中又被 JOIN 的表重复引入，冲突会再次发生——别名不会“穿透”到上层自动规避。
这意味着：
- 每一层视图都必须独立处理字段命名，不能假设下层已解决
-
SELECT *在嵌套场景下危险系数翻倍，极易漏掉某一层的冲突 - 建议给每层视图加注释说明字段来源，例如：
-- from users: user_id, from orders: order_id
最麻烦的不是写别名，而是有人在上游视图改了字段名，下游视图没同步更新别名，结果查出来数据对不上。这类问题往往要翻三层 SQL 才能定位。
