视图创建时字段名重复直接报错，只要SELECT列表中有两个同名列（如users.id和orders.id），建视图即失败，必须显式列出所有字段并为冲突字段指定语义清晰的别名（如user_id、order_id），且每层视图需独立处理命名，别名不穿透层级。
视图创建时字段名重复直接报错
只要 SELECT 列表里有两个同名列（比如 users.id 和 orders.id），建视图就会失败，不是警告，是硬性报错：ERROR 1060 (42S21): Duplicate column name 'id'（MySQL）或 ORA-00957: duplicate column name（Oracle）。这不是配置问题，是 SQL 标准强制要求列名唯一。
常见错误场景：
- 写
SELECT * FROM users JOIN orders ON users.id = orders.user_id直接建视图 - 用逗号拼接多表（
FROM users, orders）且未显式指定别名 - 嵌套视图中复用
SELECT *，下层已重命名的字段在上层又被新表引入同名字段
根本解法只有一条：显式列出所有字段，并为每个可能冲突的字段加 AS 别名。别名必须语义清晰，例如 users.id AS user_id、orders.id AS order_id，禁用 id1、id_2 这类无意义命名。
JOIN 多表时字段别名必须逐层独立处理
别名不会穿透视图层级。哪怕你已经在一个基础视图 v_users_orders 中把 users.id 命名为 user_id，当再基于它创建 v_summary 并 JOIN payments 时，如果 payments 也有 id 字段，冲突仍会爆发——v_users_orders 的别名对 v_summary 的 SELECT 列表不生效。
实操要点：
- 每一层视图都必须重新检查并处理字段命名，不能依赖下层“已解决”
- 推荐在视图定义开头加注释，说明关键字段来源，例如：
-- user_id: from users.id, order_status: from orders.status - 用
DESCRIBE v_name（MySQL）或\d v_name（PostgreSQL）验证最终列名是否唯一、可读 - 避免在别名中使用空格、连字符或中文；统一用小写下划线，如
created_at、payment_amount
DISTINCT 在视图里无法按业务逻辑去重
写 SELECT DISTINCT company, id, created_at FROM orders 创建视图，结果中 company 依然重复。因为 DISTINCT 是对整行判重，而 id 和 created_at 几乎总不同，导致“相同公司”的多条记录永远不被合并。
真正需要的是“每组取一条”，比如每个 company 只留最新那条记录。这时必须用窗口函数：
CREATE VIEW latest_company_orders AS
SELECT company, id, created_at
FROM (
SELECT company, id, created_at,
ROW_NUMBER() OVER (PARTITION BY company ORDER BY created_at DESC) AS rn
FROM orders
) t
WHERE rn = 1;注意：
-
ROW_NUMBER()在 MySQL 8.0+、PostgreSQL、SQL Server 支持，SQLite 不支持 -
DISTINCT视图无法在外层再加聚合（如COUNT(*)），而GROUP BY视图天然支持后续扩展 - 如果必须保留原始字段名对接旧系统，可用
NULL AS xxx占位，但需文档注明
最容易被忽略的陷阱：上游视图改了字段名，下游没同步
有人在基础视图里把 users.id 改成 user_id，但所有引用它的上层视图仍写 v_base.id，结果运行时报 Unknown column 'v_base.id'。这不是语法错误，是字段契约断裂。
这类问题往往在上线后才暴露，排查成本极高。最稳妥的做法是：
- 所有视图字段名变更，必须触发下游视图的代码审查和重建
- 在数据库 CI 流程中加入
SELECT * FROM v_name LIMIT 0类型的结构校验 - 避免用 ORM 的
raw()或text()查询直接依赖视图字段名，优先走模型映射
复杂点不在写别名，而在维护别名之间的依赖关系。一旦松懈，就变成靠人肉记忆和临时调试来兜底。
