多对多JOIN必须通过中间表连接，否则产生笛卡尔积；遗漏ON条件或字段不匹配导致语义错误；LEFT JOIN后WHERE劫持会失效；GROUP BY需包含所有非聚合字段；视图可固化聚合逻辑。
多对多JOIN直接爆炸是笛卡尔积在执行
不走中间表、直接JOIN两张主表（比如users和roles），数据库没别的选择，只能按笛卡尔积算：10个用户 × 5个角色 = 50行。这不是性能问题，是语义错误——你没告诉它“关系存在哪”，它就只能穷举所有组合。
常见错误写法：SELECT * FROM users u JOIN roles r（漏掉ON条件）或ON u.id = r.id（字段完全不匹配）。这类查询可能跑得慢、结果错、还难定位。
- 必须通过中间表（如
user_roles）连接，路径固定为：users → user_roles → roles - 中间表
user_roles必须有(user_id, role_id)联合唯一索引，否则同一关系存两次，JOIN时天然翻倍 - MySQL/PostgreSQL等优化器看到缺失中间表，常退化成
Hash Join并扫描全部右表，执行计划里Rows列会明显异常
LEFT JOIN中间表后仍重复？检查ON条件是否被WHERE劫持
写了LEFT JOIN user_roles ur ON u.id = ur.user_id，但后面跟了WHERE ur.role_id = 3，整条LEFT JOIN就失效了——所有ur.role_id IS NULL的用户全被过滤，实际变成INNER JOIN。
想保留无角色的用户，同时只关联角色ID为3的记录，条件必须塞进ON：LEFT JOIN user_roles ur ON u.id = ur.user_id AND ur.role_id = 3。
-
WHERE作用于JOIN后的完整结果集，会干掉NULL行 -
ON中的附加条件只影响右表匹配逻辑，不影响左表保留 - 若要查“哪些用户拥有角色3”，
EXISTS更清晰：EXISTS (SELECT 1 FROM user_roles ur WHERE ur.user_id = u.id AND ur.role_id = 3)
GROUP BY后字段对不齐，报错或结果不可靠
用LEFT JOIN连完三张表，再GROUP BY u.id，但SELECT里写了u.name, r.role_name，MySQL 5.7+会直接报错；即使旧版本放行，r.role_name取哪一行也完全不确定。
正确做法是：所有非聚合字段必须出现在GROUP BY中，或明确用聚合函数包裹。例如要拼接角色名：STRING_AGG(r.role_name, ', ')（PostgreSQL）或GROUP_CONCAT(r.role_name)（MySQL）。
-
GROUP BY u.id, u.name是安全起点，但字段越多，排序开销越大 -
GROUP_CONCAT默认长度1024，超长会被截断，需提前设group_concat_max_len - 排序不稳定会导致拼接字符串顺序乱，加
ORDER BY r.sort_order确保可重现
用视图固化多对多聚合逻辑最省心
每次查用户带角色列表都写一遍三表JOIN+GROUP BY+STRING_AGG，既重复又易错。不如建个视图，把收敛逻辑封在里面：
CREATE VIEW user_with_roles AS SELECT u.id, u.name, STRING_AGG(r.role_name, ', ') AS roles FROM users u LEFT JOIN user_roles ur ON u.id = ur.user_id LEFT JOIN roles r ON ur.role_id = r.id GROUP BY u.id, u.name;
后续查询只需SELECT * FROM user_with_roles，不用再操心中间表、分组、拼接细节。
关键点：视图里必须用LEFT JOIN保证无角色用户不丢；GROUP BY必须包含所有非聚合字段；STRING_AGG要处理NULL（PostgreSQL可用COALESCE包一层）。
真正容易被忽略的是：多对多的“展开”是关系本质决定的，不是SQL缺陷。你决定用JOIN还是EXISTS、用GROUP_CONCAT还是应用层分组，本质上是在选数据形态——是行集合，还是字段值。选错形态，后面全是补丁。
