必须走「主表 → 中间表 → 业务表」三段式JOIN，跳过中间表或写错ON字段顺序会导致结果为空或笛卡尔积爆炸；因user与role表无外键，直接JOIN会报错或生成无意义数据；中间表user_roles需严格一致的user_id和role_id字段，并通过ON条件桥接，WHERE与ON位置错误会使LEFT JOIN失效。
必须走「主表 → 中间表 → 业务表」三段式 JOIN，跳过中间表或写错 ON 字段顺序，结果不是空就是爆炸式重复——这不是慢，是逻辑错。
为什么不能直接 JOIN 两张业务表
因为 user 和 role 表之间没有外键：ON u.id = r.user_id 会报错（r.user_id 根本不存在）；换成 WHERE u.id = r.id 则触发笛卡尔积，100 个用户 × 50 个角色 = 5000 行无意义数据。
- 多对多关系在 SQL 里没有原生支持，必须靠中间表（如
user_roles）桥接 - 中间表至少含两个字段：
user_id和role_id，且类型、字符集、是否UNSIGNED必须与对应主表主键严格一致 - 漏建外键约束，可能插入不存在的
user_id或role_id - 字段名混用（比如一边叫
uid，一边叫role_id），ON条件一写就失效
LEFT JOIN 时 WHERE 和 ON 的位置决定是否丢数据
想查「所有用户及其角色（含无角色者）」，但把过滤条件放错地方，LEFT JOIN 就等于白写。
- 典型翻车：
LEFT JOIN user_roles ur ON u.id = ur.user_id WHERE ur.role_id = 3—— 这个WHERE实际把左连接“降级”了，所有没角色的用户全被干掉 - 想保留主表全部记录，只让右表匹配特定值：条件必须进
ON，例如LEFT JOIN user_roles ur ON u.id = ur.user_id AND ur.role_id = 3 - 想先完整关联，再筛结果（比如排除已删除角色）：才用
WHERE，但得确认不误筛左表字段，例如WHERE r.status = 'active' OR r.id IS NULL - 旧版 PostgreSQL 可能在
ON里不支持非等值判断（如ur.role_id = 3），得查文档
JOIN 后行数爆炸？别急着加 DISTINCT
一个用户有 3 个角色，JOIN 后自然出 3 行——这不是 bug，是关系代数的必然结果。盲目加 DISTINCT 只压平行，不解决语义歧义，还可能掩盖真实数据问题。
- 先确认业务需求：你要的是「每个用户的标签列表」，还是「带标签信息的用户明细」？前者不该用
JOIN直接查，后者才需要处理膨胀 - 要「张三 — 管理员, 编辑」这种单行展示：用
GROUP_CONCAT(r.name ORDER BY r.name)（MySQL）或STRING_AGG(r.name, ', ')（PostgreSQL），必须配GROUP BY u.id, u.name -
GROUP_CONCAT默认长度上限 1024，超长会被截断，需提前设SET SESSION group_concat_max_len = 1000000 - 中间表有
created_at想按时间排序合并：MySQL 要写GROUP_CONCAT(r.name ORDER BY ur.created_at)，其中ur是中间表别名
最容易被忽略的是中间表字段类型与主表外键的严格一致性——哪怕只是 INT 和 INT UNSIGNED 的差异，也可能导致索引失效或隐式转换，让 JOIN 变慢甚至返回空结果。
