视图字段别名必须明确唯一且语义清晰，而非数量越多越好；需为同名列、聚合字段、表达式等显式指定无冲突、非保留字、不含特殊字符的别名，否则将导致查询失败、数据错乱或维护困难。
视图字段别名不是越多越好，而是越明确越安全
在视图定义中，**必须为所有可能冲突或语义不清的字段显式指定别名**，但“过多”本身不是问题——真正危险的是别名混乱、重复、或掩盖业务含义。很多团队误以为“全加别名=更规范”，结果反而让视图更难维护。
别名重复或命名模糊会导致下游查询失败
常见错误现象：CREATE VIEW v_user_order AS SELECT u.id, o.id FROM users u JOIN orders o ON u.id = o.user_id; 在 PostgreSQL 或 SQL Server 中直接报错 ERROR: column "id" specified more than once；即使 MySQL 允许创建，后续 SELECT id FROM v_user_order 会返回第一个 id（通常是 users.id），而 orders.id 被静默丢弃。
- 必须为每个同名列单独起唯一别名，例如：
u.id AS user_id和o.id AS order_id - 别名不能只是加前缀了事，比如
u.status AS status和o.status AS status—— 这仍算重复，且完全失去区分意义 - 别名里含空格或特殊字符（如
"Order Date"）需用双引号包裹，但 ORM 或 BI 工具常不兼容，建议统一用下划线（order_date）
聚合字段或表达式不加别名会让视图无法被引用
视图中用了 SUM(amount) 却没写 AS total_amount，那调用方写 SELECT total_amount FROM v_sales 就会失败，因为实际列名可能是 sum(amount) 或 expr1，取决于数据库方言。
-
GROUP BY子句里不能直接用未定义的别名，例如GROUP BY dept_name前必须先在SELECT中有dept.name AS dept_name - 某些旧版 MySQL 对未别名的聚合列做
ORDER BY会静默忽略，导致排序结果不稳定 - 别名不是“装饰”，是视图对外暴露的契约：一旦定下
user_status，所有下游代码、报表、API 都按这个名来取值，改名等于破坏接口
别名掩盖字段来源，反而增加排查成本
一个视图里把 users.status、orders.status、payments.status 全映射成 status，哪怕加了不同前缀（user_status、order_status、payment_status），如果业务逻辑没注释清楚，半年后谁也说不准哪个状态机对应哪张表的状态流转。
- 别名应反映真实语义，而不是单纯“去重”：比如
COALESCE(u.phone, u.mobile) AS contact_phone比COALESCE(u.phone, u.mobile) AS phone更准确 - 避免用 SQL 保留字作别名（如
order、user、desc），否则查询时必须加引号，徒增出错概率 - 子查询作为视图主体时，内部每列也必须别名——外层无法靠位置引用，只能靠名字，漏一个就整个视图失效
