三表JOIN必须通过中间表关联，如user→user_role→role，跳过中间表会导致空结果或笛卡尔积；LEFT JOIN中过滤条件须放ON子句以保留主表全部记录，放WHERE会使其退化为INNER JOIN。
三表JOIN必须走「主表 → 中间表 → 业务表」路径
跳过中间表或颠倒顺序，结果不是空就是爆炸式重复——这不是慢，是逻辑错。比如 user 和 role 没有外键，硬写 JOIN role r ON u.id = r.user_id 直接报错；换成 WHERE u.id = r.id 则触发笛卡尔积，100 × 50 = 5000 行垃圾数据。
正确路径只有一条：user → user_role → role。中间表字段名必须统一为 user_id 和 role_id，别混用 uid/rid，否则 ON 条件一写就失效。
- 查「所有用户及其角色（含无角色者）」：以
user为主表，LEFT JOIN user_role ON u.id = ur.user_id，再LEFT JOIN role ON ur.role_id = r.id - 查「角色 3 对应的所有用户」：用
INNER JOIN更安全，避免NULL干扰后续聚合 - 别在 SQL 里硬拼 JSON 或逗号分隔字符串模拟多对多——
LIKE '%3%'全表扫描、无法加索引、更新不原子
LEFT JOIN 时 WHERE 和 ON 的位置决定是否丢数据
把过滤条件放错地方，LEFT JOIN 就等于白写。典型翻车：LEFT JOIN user_role ur ON u.id = ur.user_id WHERE ur.role_id = 3 —— 这个 WHERE 实际把左连接“降级”了，所有没角色的用户全被干掉。
想保留主表全部记录，只让右表匹配特定值：条件必须进 ON，例如 LEFT JOIN user_role ur ON u.id = ur.user_id AND ur.role_id = 3。
想先完整关联，再筛结果（比如排除某些状态）：才用 WHERE，但得确认不误筛左表字段。注意：MySQL 允许在 ON 里写非等值判断（如 ur.role_id = 3），但旧版 PostgreSQL 可能不支持，得查文档。
GROUP_CONCAT / STRING_AGG 合并多个关联值
一个用户有 3 个角色，JOIN 后自然出 3 行——这不是 bug，是关系代数的必然结果。盲目加 DISTINCT 只压平行，不解决语义歧义，还可能掩盖真实数据问题。
要合并成单行字符串，必须用聚合函数：
- MySQL 用
GROUP_CONCAT(r.name ORDER BY r.name)，默认长度上限 1024，超长会被截断，需提前设SET SESSION group_concat_max_len = 1000000 - PostgreSQL 用
STRING_AGG(r.name, ', ')，9.6+ 才支持ORDER BY子句，旧版本得套子查询 - 中间表有额外字段（如
created_at）想按时间排序合并：MySQL 写GROUP_CONCAT(r.name ORDER BY ur.created_at)，其中ur是中间表别名 - 必须配
GROUP BY u.id, u.name，否则 MySQL 5.7+ 严格模式直接报错
中间表没联合索引，JOIN 性能直接掉坑里
中间表字段类型必须与主表外键严格一致（比如都是 BIGINT UNSIGNED），否则隐式转换导致索引失效。
联合索引必须覆盖常用查询路径：INDEX (user_id, role_id) 支持「查某用户所有角色」，INDEX (role_id, user_id) 支持「查某角色所有用户」。单列索引没用，(user_id) 无法加速 WHERE role_id = ?。
如果中间表还有状态字段（如 is_active），且常用于过滤，考虑扩展为 INDEX (role_id, is_active, user_id)，让查询能走覆盖索引。
