视图中DISTINCT无效的根本原因是字段名重复导致视图创建失败，而非去重逻辑失效；必须为JOIN结果中所有列显式指定唯一别名，否则数据库在CREATE VIEW阶段直接报错。
视图里用 DISTINCT 为什么有时没效果
不是 DISTINCT 失效，而是它只对当前 SELECT 的整行结果去重——如果字段名重复（比如两个 id），视图根本建不起来，DISTINCT 根本没机会执行。MySQL、PostgreSQL、SQL Server 都会在 CREATE VIEW 阶段直接报错：ERROR 1060 (42S21): Duplicate column name 'id'。所以“避免重复数据”之前，得先让视图能创建成功。
常见错误写法：SELECT DISTINCT o.id, u.id FROM orders o JOIN users u ON o.user_id = u.id —— 这条语句在创建视图时就会失败，连语法校验都过不了。
- 必须先解决字段名冲突：每个输出列都要有唯一别名，如
o.id AS order_id、u.id AS user_id -
DISTINCT只能放在SELECT后紧邻位置，不能带独立ORDER BY（视图定义中会被忽略或报错） - 如果基表本身有重复逻辑（比如一对多关系未聚合），
DISTINCT可能掩盖问题而非解决——它删的是行，不是业务意义上的“冗余”
JOIN 场景下如何防止视图字段重复
90% 的视图建不起来，是因为 JOIN 时没处理字段名歧义。数据库不关心你“知道哪个 id 是订单的”，它只认最终投影结果里的列名是否唯一。
错误示范：SELECT id, name, status FROM orders JOIN customers ON orders.customer_id = customers.id —— 两张表都有 id、name、status，视图定义直接失败。
- 所有字段必须显式加表前缀 +
AS别名，例如：orders.id AS order_id、customers.name AS customer_name - 即使某字段当前唯一（如
orders.created_at），也建议加前缀，否则后续加新表（比如products）会突然崩掉视图 - LEFT JOIN 右表字段即使全为
NULL，也得命名——视图结构是静态定义的，不依赖运行时数据 - 别名避开保留字，比如不用
order、group、user，否则某些数据库（如 PostgreSQL）可能报语法错误
子查询和表达式字段必须命名
函数、计算字段、常量这些看似“不会撞名”的东西，在视图里一样要 AS。否则数据库会生成不可靠默认名（如 UPPER(name) 或 expr_1），导致 ORM 映射失败或下游 SQL 报错。
典型问题：SELECT UPPER(name), COUNT(*) FROM users GROUP BY UPPER(name) 直接用于视图会出问题——第一个字段没别名，第二个字段名是 COUNT(*)，含括号且不可引用。
- 正确写法：
UPPER(name) AS upper_name、COUNT(*) AS user_count - 子查询作为表源时，内部字段也必须别名化，例如：
(SELECT id AS user_id, email AS user_email FROM users) u - 聚合字段尤其不能省略别名，
GROUP BY和视图外部查询都依赖这个名称
DISTINCT 视图的更新限制与性能隐患
能建成功的 DISTINCT 视图，通常不可更新。这不是 bug，是设计使然：去重后一行可能对应多行原始数据，数据库无法确定该更新哪一条。
更隐蔽的问题是性能——视图不存数据，每次查 SELECT * FROM v_distinct_users 都会触发全表扫描 + 排序去重。如果基表大且没索引，延迟飙升。
- 确认是否真需要封装进视图：如果只是报表临时去重，应用层加
DISTINCT更灵活 - 若必须用视图，确保
DISTINCT涉及的字段组合有联合索引，比如(status, created_at) - 不要指望
DISTINCT解决“取最新一条”这类逻辑——它只删重复行，不选优；该用ROW_NUMBER()或GROUP BY+ 聚合函数 - PostgreSQL 和 SQL Server 对
DISTINCT视图的优化能力弱于 MySQL，跨库迁移时需额外验证
字段名冲突发生在 CREATE VIEW 执行那一刻，不是查询时；哪怕你后续只 SELECT order_id，只要定义里有两个 id，视图就建不起来。别名不是为了好看，是让视图结构可定义、可映射、可维护。
