left join 行数增多是语义正确，非 bug；应通过子查询聚合、row_number() 或 exists 控制右表粒度，而非依赖 distinct 去重。
LEFT JOIN 重复是语义正确，不是 bug
看到结果行数比左表多，别急着改 SQL —— 这恰恰说明 LEFT JOIN 没出错。它的定义就是：左表每行，匹配右表所有满足 ON 条件的行。如果 users.id = 1 在 t_log 里有 4 条记录，那这用户信息就必然出现 4 次。
常见误判包括：
-
COUNT(*)统计 JOIN 结果，当成“用户数”，实际是“用户 × 日志条数” - 后续再
JOIN第三张表，拿这个已膨胀的结果当主表，错误级联放大 - 以为加了
DISTINCT就万事大吉，但只要log_time或ip_addr有一列不同，整行就不被去重
为什么 DISTINCT 几乎总是无效
DISTINCT 是对 SELECT 列表所有字段的组合值去重，不是按 user_id 单列“智能合并”。它解决不了逻辑膨胀，只在表面擦除。
萃智引擎 (TRIZ Engine)
下载
一款AI图像与设计工具，主要用于基于TRIZ理论的AI工程创新平台，为工程师提供复杂机械机理实时渲染、物理级运动仿真、矛盾矩阵求解及AI创新灵感生成，适合需要提升相关任务效率的用户。
典型失效场景：
-
SELECT DISTINCT u.id, u.name FROM users u LEFT JOIN t_log l ON u.id = l.user_id看似去重，但一旦加上l.log_time，重复立刻回来 - MySQL 5.7+ 严格模式下，
DISTINCT和聚合函数混用可能触发ONLY_FULL_GROUP_BY报错 -
DISTINCT在某些引擎中会隐式排序，大表查询明显变慢
真正该做的：在 JOIN 前让右表只输出一行
核心思路是控制右表输出粒度，而不是在结果上打补丁。选哪种方式，取决于你要什么：
- 要汇总值（如登录次数、最新 IP）→ 用子查询 +
GROUP BY：SELECT u.id, u.name, p.cnt, p.max_ip FROM users u LEFT JOIN (SELECT user_id, COUNT(*) AS cnt, MAX(ip_addr) AS max_ip FROM t_log GROUP BY user_id) p ON p.user_id = u.id - 要完整单条明细（如最新一条日志）→ 用
ROW_NUMBER()，且rn = 1必须写在ON子句里：SELECT u.id, u.name, p.ip_addr, p.log_time FROM users u LEFT JOIN (SELECT user_id, ip_addr, log_time, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY log_time DESC, id DESC) AS rn FROM t_log) p ON p.user_id = u.id AND p.rn = 1 - 只判断“有没有关联记录”→ 改用
EXISTS：SELECT * FROM users u WHERE EXISTS (SELECT 1 FROM t_log l WHERE l.user_id = u.id)
容易被忽略的关键细节
AND p.rn = 1 写在 WHERE 而不是 ON，会让 LEFT JOIN 退化成 INNER JOIN，丢失没日志的用户；ORDER BY log_time DESC 如果存在时间戳完全相同的情况，ROW_NUMBER() 每次执行顺序可能不同——必须补上唯一字段做二级排序，比如 ORDER BY log_time DESC, id DESC；右表关联字段若类型不一致（如 users.id 是 INT，t_log.user_id 是 VARCHAR），JOIN 可能退化为全表扫描甚至笛卡尔积。
