视图定义中必须用AS为每列显式指定别名，因视图列名完全由SELECT子句中的别名决定；省略AS会导致列名不可预测、同名列冲突或创建失败，且WHERE/HAVING中不可引用该别名。
视图定义里必须用 AS 给列起别名
视图的列名完全由 SELECT 子句中定义的别名决定，数据库不会自动继承原表列名。如果 SELECT 中有表达式、函数或多个表的同名列，不显式加 AS 会导致视图创建失败或列名不可预测（比如显示为 expr1、CONCAT(...) 这类系统生成名）。
常见错误现象：CREATE VIEW v_users_orders AS SELECT u.name, o.order_id FROM users u, orders o; —— 这个语句在多数数据库（如 PostgreSQL、SQL Server）中会报错，因为列名不明确；MySQL 虽允许，但视图列名是 name 和 order_id，一旦 users 和 orders 都有 name 列，就直接冲突。
- 必须为每个输出列指定唯一、明确的别名，尤其是多表 JOIN 场景
-
AS关键字不能省略（即使某些方言支持空格省略，在视图中也强烈建议保留，避免兼容性问题） - 别名里含空格或特殊字符时，用双引号包裹，如
"Full Name"，但生产环境应优先用下划线命名（如full_name）
多表同名列必须靠表别名 + 列别名双重隔离
当 users.id 和 orders.user_id 同时出现在 SELECT 中，只靠表别名 u、o 不足以解决视图列名冲突——视图最终暴露的是结果集列名，不是引用路径。
正确做法是：先用表别名消除引用歧义，再用列别名确保输出列名唯一且语义清晰。
- 错误写法：
SELECT u.id, o.user_id FROM users u JOIN orders o ON u.id = o.user_id;→ 视图会报“重复列名”或只保留第一个id - 正确写法：
SELECT u.id AS user_id, o.id AS order_id, o.user_id AS order_user_id FROM users u JOIN orders o ON u.id = o.user_id; - 特别注意：子查询作为视图主体时，子查询内部也必须给所有列起别名，否则外层无法引用
GROUP BY 或聚合字段在视图里必须带别名
视图中若含 SUM()、COUNT()、AVG() 等聚合函数，或配合 GROUP BY，不加别名会导致后续查询无法按业务含义引用该列，比如 SELECT total FROM v_sales_summary 会失败，因为实际列名可能是 sum(amount)。
更隐蔽的问题是：某些数据库（如 older MySQL）在视图中对未别名的聚合列做 ORDER BY 会静默忽略排序，导致结果不稳定。
- 必须写成：
SUM(amount) AS total_amount，而不是SUM(amount) - 如果
GROUP BY用到了别名（如GROUP BY dept_name），确保该别名已在 SELECT 中定义，否则报错（标准 SQL 要求GROUP BY引用的是 SELECT 列或原始字段） - 别名不要和原表字段名完全一致，否则可能掩盖字段来源，增加维护成本
别名作用域限制：WHERE 和 HAVING 里不能直接用列别名
这是最容易踩的坑——很多人在视图定义里写了 price * 1.1 AS final_price，然后想在同一个视图里写 HAVING final_price > 100，结果报错。
原因：SQL 执行顺序是 FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY，而别名只在 SELECT 阶段生成，WHERE 和 HAVING 都早于它执行。
- 在视图定义中，
WHERE条件必须用原始字段或表达式，如WHERE price * 1.1 > 100，不能写WHERE final_price > 100 - 同理，
HAVING必须基于聚合表达式本身，而非其别名 - 若逻辑复杂，考虑用 CTE 替代视图，CTE 中可分步定义别名并复用
视图里的别名不是语法糖，而是结构契约——它决定了下游所有查询能“看到什么名字”。一旦定义，就不能靠 ALTER VIEW 修改列名（多数数据库不支持），只能重建。所以第一次写就要想清楚业务语义，别图省事漏掉 AS。
