PostgreSQL和SQL Server中CREATE VIEW时列别名缺失直接报错，MySQL则静默覆盖同名列导致数据不可靠；WHERE/GROUP BY不可引用SELECT别名，因执行顺序限制；ClickHouse要求别名在GROUP BY中严格一致；视图列名固化为契约，改名将破坏所有下游依赖。
视图创建时列别名缺失直接报错或静默覆盖
PostgreSQL 和 SQL Server 在 CREATE VIEW 中遇到未显式命名的列会立即拒绝执行，比如 SELECT u.id, o.id FROM users u JOIN orders o ON u.id = o.user_id —— 两个 id 都没加 AS，建视图就失败。MySQL 虽可能成功，但生成的视图列名是两个 id，实际只能访问后一个，前一个被覆盖。这种“看似成功、实则错漏”的行为，会让下游查询返回空值、错值，却查不出源头问题。
WHERE/GROUP BY 引用 SELECT 别名导致 Unknown column 错误
SQL 执行顺序是 FROM → WHERE → GROUP BY → SELECT → ORDER BY，WHERE 根本看不到 SELECT 里定义的别名。写了 SELECT u.status AS user_status，再写 WHERE user_status = 'active'，必然报 Unknown column 'user_status'。这不是语法错误，而是逻辑断层：你误以为别名“全局可见”，其实它只在 SELECT 和后续子句生效。
- 正确做法只有两种：回退到原始引用，如
WHERE u.status = 'active' - 或用 CTE / 子查询提前计算并命名，让该字段成为“输入列”而非“计算列”
ClickHouse 等引擎对别名一致性要求极严
ClickHouse 不允许在 GROUP BY 或 HAVING 中混用原始列名和别名。例如：SELECT a.event_type2_id AS event_type2 FROM table_a a GROUP BY a.event_type2_id 会报解析错误；必须统一为 GROUP BY event_type2。它的解析器不尝试“推导等价性”，只做字面匹配。一旦嵌套子查询中别名命名不一致（比如内层叫 sub_evt，外层 GROUP BY 写 a.event_type2_id），整个查询就挂掉，且错误提示常不指明具体哪一层出问题。
视图字段名固化成契约，改名即破下游
视图一旦创建成功，它的列名就写死在系统元数据里了。哪怕你只是把 user_id 改成 uid，所有硬编码该字段名的应用、报表、ETL 脚本都会立刻崩。更麻烦的是，这类错误往往在部署后才暴露——开发库跑得通，上线连不上字段，日志里只显示 Column not found，根本看不出是视图改名惹的祸。修复成本远高于预防：必须同步更新所有消费者，还得考虑灰度兼容。
