视图定义中禁用 SELECT *，因多表 JOIN 时同名列会导致“ambiguous column name”错误；所有字段须显式指定表前缀或唯一别名，调用时亦需使用视图暴露的列名。
视图定义里用了 SELECT * 就容易出 ambiguous column name
视图一旦基于多表 JOIN，又用了 SELECT *，后续只要两张表有同名列（比如 id、name、created_at），创建或调用时就会报 Ambiguous column name。数据库不是不认字段，而是根本没法决定这个 id 该从哪张表取。
常见错误写法：
CREATE VIEW user_order_summary AS SELECT *, o.status, u.email FROM users u JOIN orders o ON u.id = o.user_id;
这里 * 已经把 u.id 和 o.id 都拉进来了，再额外写 o.status，数据库在解析字段列表阶段就卡住——id 到底算谁的？
- 永远别在视图中用
SELECT *，哪怕当前只有一张表有某字段 - 视图是长期复用的结构，表结构可能后续加字段，同名风险只会增加
- 用
pg_get_viewdef()（PostgreSQL）或SHOW CREATE VIEW（MySQL）检查现有视图实际展开的字段，确认有没有隐式重复
ORDER BY 或 GROUP BY 里漏了表前缀也会触发
视图定义本身可能没报错，但一执行 SELECT * FROM user_order_summary ORDER BY id 就崩。因为 ORDER BY 的 id 没带前缀，数据库无法绑定到具体来源列。
即使视图字段列表里每个列都带了别名（如 u.id AS user_id），只要你在查询视图时的 ORDER BY、WHERE 或 HAVING 子句里直接写裸列名，歧义就回来了。
- 调用视图时，所有涉及列引用的地方——包括
WHERE、ORDER BY、GROUP BY、HAVING——都必须用视图暴露出来的列名，不能回退到原表字段名 - 如果视图暴露的是
user_id和order_id，那就只能写ORDER BY user_id，不能写ORDER BY u.id - 别指望“视图里已经区分了，外面就能省略”，SQL 解析是分层的：视图定义层解决字段来源，调用层解决字段引用
嵌套视图让歧义更难定位
当视图 A 基于视图 B，而 B 又 JOIN 了三张表，其中两张有 code 字段，这时 A 中只要出现未限定的 code，错误堆栈往往只提示最外层 SQL，不会告诉你问题藏在 B 的定义里。
排查路径很实际：
- 先运行
SELECT * FROM <内层视图名>，看是否能查出——如果这一步就报错，说明歧义在视图定义内部 - 用
pg_views（PostgreSQL）或INFORMATION_SCHEMA.VIEWS查出视图文本，逐行检查所有列是否都明确归属（含GROUP BY子句里的字段） - 临时把嵌套视图展开成等价的多表 JOIN 写法，复现并精简问题 SQL，比对着元数据猜快得多
别名冲突比表名冲突还隐蔽
你以为用了别名就安全了？不一定。比如：
CREATE VIEW v AS SELECT u.id, o.id AS id, u.name FROM users u JOIN orders o ON u.id = o.user_id;
这里两个 id 字段一个没加别名、一个显式 AS id，结果视图字段列表里出现两个 id，直接违反 SQL 标准（列名必须唯一），多数数据库会拒接创建，但有些（如旧版 SQL Server）可能容忍，后续查询时就爆 Ambiguous column name 'id'。
- 视图中所有
SELECT子句的列名必须全局唯一，不能靠“一个来自 u，一个来自 o”来区分 -
AS别名优先级高于表前缀，一旦写了o.id AS id，它就覆盖了u.id的原始名，导致冲突 - 建视图前用工具或脚本扫一遍
AS后的别名是否重复，比上线后 debug 省力得多
真正麻烦的不是语法改写，而是团队里有人觉得“现在没冲突，以后加字段再说”。可一旦视图被几十个报表、API、定时任务引用，改起来就是连锁反应。字段来源这件事，必须在定义视图的第一行就钉死。
