必须走「主表 → 中间表 → 业务表」三段式 JOIN，跳过中间表或写错 ON 字段顺序会导致逻辑错误；多对多关系必须通过结构规范、索引完备的中间表桥接，且字段类型与主表外键严格一致。
必须走「主表 → 中间表 → 业务表」三段式 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_roles，别用user_role_map这类模糊名 - 漏建外键约束，可能插入不存在的
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(t.name ORDER BY ur.created_at)，其中ur是中间表别名
中间表没索引？JOIN 性能直接掉坑里
多对多查询慢，90% 是因为 user_roles 这类中间表缺联合索引。它既被 user_id 驱动，也被 role_id 驱动，但单列索引几乎无效。
- 必须建联合索引：
CREATE INDEX idx_user_roles_user_id ON user_roles(user_id, role_id)（按常用 JOIN 方向排） - 如果常反向查「某个角色下所有用户」，再补一个：
CREATE INDEX idx_user_roles_role_id ON user_roles(role_id, user_id) - 别忽略
FOREIGN KEY约束：它不光保数据一致性，还能帮优化器更好估算行数
最易被忽略的一点：中间表字段类型和主表外键不一致（比如主表 id 是 BIGINT UNSIGNED，中间表 user_id 却是 INT），会导致索引失效、隐式转换、JOIN 变慢甚至结果错误。
