LEFT JOIN行数暴增主因是隐式笛卡尔积或一对多未收敛，需通过执行计划Rows字段定位；必须用中间表（如user_role）连接多对多关系，ON条件须含过滤逻辑，GROUP BY需与SELECT字段对齐，区分关联逻辑与展示需求。
LEFT JOIN后行数暴增，先看执行计划里的“Rows”字段
数据库执行计划里显示的 Rows 值异常高（比如左表100行，右表1000行，但 Nested Loop 的 inner rows 显示 5000+），基本能确认是隐式笛卡尔积或一对多未收敛。这不是数据错，是JOIN逻辑没对齐业务意图。
- 用
EXPLAIN ANALYZE（PostgreSQL）或EXPLAIN FORMAT=TREE（MySQL 8.0+）查实际扫描行数，别只看预估 - 重点盯
Join Type和Rows列：如果出现Hash Join且右侧Rows是左表的整数倍，大概率是中间表没加过滤或ON条件漏字段 - 临时把所有
JOIN改成LEFT JOIN，再加WHERE right_table.id IS NULL，能快速验证是否存在“本不该匹配却强行连上”的逻辑漏洞
多对多查询漏了中间表，结果集直接爆炸
直接 JOIN user 和 role 表，不经过 user_role，等于让数据库自己猜关系——它只能按笛卡尔积算，10个用户 × 5个角色 = 50行，哪怕你只想要“每个用户的角色列表”。
- 必须走三段路径：
user → user_role → role，中间表是强制桥梁，不是可选项 -
user_role表必须有(user_id, role_id)联合主键或唯一索引，否则同一关系可能重复插入，JOIN时天然放大 - 别在
ON条件里写UPPER(r.name) = 'ADMIN'这类函数，索引失效后，数据库可能放弃走索引而全表扫，间接加剧重复风险
WHERE里写中间表字段，LEFT JOIN当场变INNER JOIN
写成 LEFT JOIN user_role ON u.id = ur.user_id WHERE ur.role_id = 3，效果等同于 INNER JOIN：所有 ur.role_id IS NULL 的用户（即没角色的用户）全被干掉，还自以为用了LEFT。
- 想保留无角色用户，同时只关联角色ID为3的记录，条件必须塞进
ON：LEFT JOIN user_role ON u.id = ur.user_id AND ur.role_id = 3 - 如果要查“所有用户中哪些拥有角色3”，
EXISTS更清晰：EXISTS (SELECT 1 FROM user_role ur WHERE ur.user_id = u.id AND ur.role_id = 3) - 用
IN也行，但注意子查询结果含NULL会让整个条件返回UNKNOWN，推荐改用NOT EXISTS防坑
聚合合并时GROUP BY列没对齐SELECT字段
写 SELECT u.name, r.role_name FROM user u LEFT JOIN user_role ur ON ... LEFT JOIN role r ON ... GROUP BY u.id，MySQL 5.7+ 会直接报错——u.name 和 r.role_name 没出现在 GROUP BY 里，也没用聚合函数包裹。
- 要输出用户+角色列表字符串，得用
STRING_AGG(r.name, ', ')（PG）或GROUP_CONCAT(r.name)（MySQL），并确保GROUP BY u.id且 SELECT 中所有非聚合字段都参与分组 - MySQL 的
GROUP_CONCAT默认长度上限 1024，超长会被截断，上线前务必设SET SESSION group_concat_max_len = 10000 - 如果中间表有
created_at字段，想按时间排序合并角色名，MySQL 要写GROUP_CONCAT(r.name ORDER BY ur.created_at)，别漏掉中间表别名ur
真正难的不是语法，是分清“我要关联什么”和“我要呈现什么”。一行用户数据配三行角色，是关系存在；把它压成一行带逗号的字符串，是展示需求。混淆这两层，所有去重操作都在掩盖问题。
