join后数据条数变多是正常行为，因左表一行匹配右表n行则生成n行；右表关联键不唯一导致膨胀，需在join前用子查询聚合或row_number()控制粒度，而非依赖distinct。
JOIN 后数据条数变多，不是 SQL 写错了，也不是数据库算错了，而是 JOIN 本身在按标准严格执行——左表一行匹配右表 N 行，结果就生成 N 行。这是正常行为，不是 bug。
LEFT JOIN 行数暴增是标准行为，不是错误
数据库严格遵循 SQL 标准：只要 ON 条件成立，左表某行匹配右表多少行，结果里就出现多少行。比如 users 表有 100 行，t_log 表中 user_id = 5 出现了 7 次，那用户 ID=5 这一行就会在结果中重复 7 次。
- 这不是数据“变多了”，是逻辑展开——你原本查的是“用户”，JOIN 后实际查的是“用户 × 日志”组合
-
COUNT(*)统计的是物理行数，不是业务意义上的“用户数” - 后续再 JOIN 第三张表时，这个已膨胀的结果会作为新主表，错误被级联放大
右表关联键不唯一是最常见原因
你以为 customer_id 在 customers 表里是唯一的，但实际可能因历史导入、多系统同步或缺失约束而重复。
- 快速验证：
SELECT customer_id, COUNT(*) FROM customers GROUP BY customer_id HAVING COUNT(*) > 1 - 检查约束：
SHOW CREATE TABLE customers看customer_id是否有UNIQUE或PRIMARY KEY - 如果用的是视图或子查询，重复可能藏在中间层，得把子查询单独拎出来跑一遍
DISTINCT 不能真正解决一对多膨胀
DISTINCT 是对整行去重，不是按 user_id 单列“智能合并”。只要任意一列不同（比如 log_time 差几毫秒、ip_addr 不同），整行就不被去重。
- 加了
SELECT DISTINCT u.id, u.name看似干净，一旦加上l.log_time，重复立刻回来 - 某些引擎中
DISTINCT会触发隐式排序，大表查询明显变慢 - 它掩盖了右表未收敛的问题，后续导出、聚合、再 JOIN 都可能出错
真正有效的解法：JOIN 前控制右表粒度
核心思路是让右表在 JOIN 前只输出你需要的那一行，而不是在结果上打补丁。
- 要汇总值（如登录次数、最新 IP）：
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 - 要单条明细（如最新一条日志）：
LEFT JOIN (SELECT user_id, ip_addr, log_time, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY log_time DESC) AS rn FROM t_log) p ON p.user_id = u.id AND p.rn = 1—— 注意p.rn = 1必须写在ON里，写在WHERE会丢掉没日志的用户 - 只判断“有没有关联记录”：
EXISTS更准确、无重复、性能更好，SELECT * FROM users u WHERE EXISTS (SELECT 1 FROM t_log l WHERE l.user_id = u.id)
最容易被忽略的一点：JOIN 后的结果集，已经不是原始左表的行集合了。哪怕你只 SELECT 左表字段，中间的数据膨胀过程依然发生，内存、CPU、网络传输全在为这些重复行买单。
