LEFT JOIN重复是语义必然结果，非视图问题；DISTINCT无效因右表字段导致行唯一；应通过GROUP BY聚合或ROW_NUMBER()筛选前置收敛右表，且过滤条件须置于ON而非WHERE。
LEFT JOIN重复不是视图问题，是JOIN语义本身
视图只是封装了SELECT语句，它不改变SQL执行逻辑。你看到的重复，和直接执行那条带LEFT JOIN的查询一模一样——只要右表对同一个连接键（如user_id）有N条记录，左表那行就会被复制N次。这不是视图“出bug”，而是LEFT JOIN在严格履行关系代数定义。
为什么在视图里加DISTINCT没用
DISTINCT作用于最终SELECT字段组合，不是按主键去重。一旦你从右表选了log_time、ip_addr这类可变字段，哪怕同一用户，每条日志时间都不同，整行就都不重复。DISTINCT根本不会合并它们。
- 写
SELECT DISTINCT u.id, u.name FROM view_name看似去重，但丢掉了所有右表字段 - 只要加上
l.log_time，重复立刻回来，且DISTINCT完全失效 - 大表上
DISTINCT常触发隐式排序，性能陡降，还掩盖了真正的一对多问题
真正该在视图里做的：右表预收敛
视图要稳定、可复用，就得在定义时就把右表“压扁”成1:1粒度。不能靠下游再加工，否则每次调用都膨胀，下游再JOIN第三张表会级联放大。
- 要聚合值（如登录次数、最新IP）→ 用子查询+
GROUP BY：LEFT JOIN (SELECT user_id, COUNT(*) AS login_cnt, MAX(ip_addr) AS last_ip FROM login_logs GROUP BY user_id) l ON u.id = l.user_id
- 要完整单条明细（如最新一条日志）→ 用
ROW_NUMBER()窗口函数，且rn = 1必须写在ON里：LEFT JOIN (SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY log_time DESC) AS rn FROM login_logs) l ON u.id = l.user_id AND l.rn = 1
- 只判断“有没有”→ 改用
EXISTS子查询，逻辑干净、无重复、性能通常更好
最容易被忽略的ON条件陷阱
视图定义里ON子句漏条件或错放过滤，会导致结果不可控。比如把l.status = 'active'写在WHERE里，整个视图的LEFT JOIN就退化成INNER JOIN——没匹配记录的左表行全消失，你还以为视图“漏数据”。
- 右表过滤条件必须进
ON，不能放WHERE -
ON里避免LIKE、UPPER()等非SARGable表达式，否则索引失效，JOIN可能退化为嵌套循环全扫 - 确认右表连接字段是否有
UNIQUE或PRIMARY KEY约束；没有的话，“重复”就是数据库按规则给出的确定性结果，不是偶然
视图里的LEFT JOIN重复，本质是右表未收敛就参与连接。解决它不靠擦除（DISTINCT），而靠前置控制——要么压成一行（GROUP BY），要么筛出一行（ROW_NUMBER()），且关键条件位置（ON vs WHERE）绝不能错。
