SQL 多对多关系的 JOIN 查询写法

9次阅读

多对多关系必须通过中间表实现,即两张主表加一张关联表(如user_roles),直接JOIN主表会导致笛卡尔积;正确方式是先JOIN主表到中间表,再JOIN中间表到另一主表。

SQL 多对多关系的 JOIN 查询写法

多对多关系必须通过中间表 JOIN

sql 里没有原生的“多对多”字段类型,所有多对多关系都得靠三张表实现:两张主表 + 一张关联表(也叫 junction table、bridge table)。比如 usersroles 是多对多,就必须有 user_roles 表,里面至少含 user_idrole_id 两个外键。

直接 JOIN users TO roles 会出错或产生笛卡尔积——除非你故意要交叉匹配,否则结果完全不可控。

正确做法永远是:先 JOIN 主表到中间表,再 JOIN 中间表到另一主表。顺序不重要,但路径不能跳过中间表。

查某个用户的所有角色:INNER JOIN 最常用

这是最典型的场景,目标明确、数据完整。用 INNER JOIN 能自然过滤掉没分配角色的用户,也避免空值干扰。

select u.name, r.role_name FROM users u INNER JOIN user_roles ur ON u.id = ur.user_id INNER JOIN roles r ON ur.role_id = r.id WHERE u.id = 123;

  • 别漏掉中间表的 ON 条件,尤其是两次 JOIN 的连接字段要一一对应
  • 如果想查用户基本信息+角色列表,SELECT 里不要只写 r.*,容易和 u.* 字段名冲突;用别名或显式列名更安全
  • WHERE 放在最后,别写在两个 JOIN 中间,否则可能意外改变连接逻辑

查所有用户,包括没角色的:LEFT JOIN 配合 IS NULL

当业务要求“展示全部用户,角色为空也显示”时,就得把 users 当驱动表,用 LEFT JOIN 拉中间表,再 LEFT JOIN 角色表。但注意:第二次 LEFT JOINON 条件不能写成 ur.role_id = r.id AND r.deleted = 0 这类带过滤的条件——它会把本该保留的空行变成 NULL,等效于 INNER JOIN

需要过滤角色状态时,应把条件移到 WHERE 或用子查询预处理中间表。

  • 正确写法:LEFT JOIN roles r ON ur.role_id = r.id,然后 WHERE r.status = 'active' OR r.id IS NULL
  • 错误写法:LEFT JOIN roles r ON ur.role_id = r.id AND r.status = 'active' —— 这会让无角色用户的 r.id 变成 NULL,但你也拿不到这些用户了
  • 如果中间表本身有状态字段(如 user_roles.is_active),那它的过滤条件必须放在 ON 里,否则会连出无效关联

GROUP_CONCAT 或 STRING_AGG 合并多角色

默认一条用户记录配一条角色记录,查一个用户有 5 个角色就会返回 5 行。多数前端或报表需要“一行一用户 + 角色逗号拼接”,就得聚合。

mysqlGROUP_CONCATpostgresqlSTRING_AGG,SQL Server 用 STRING_AGG(2017+)或 for xml(旧版)。

SELECT u.name, GROUP_CONCAT(r.role_name SEPARATOR ', ') FROM users u JOIN user_roles ur ON u.id = ur.user_id JOIN roles r ON ur.role_id = r.id GROUP BY u.id, u.name;

  • GROUP BY 必须包含所有非聚合字段,否则 MySQL 8.0+ 会报错
  • 如果某用户没角色,GROUP_CONCAT 返回 NULL,可用 COALESCE(GROUP_CONCAT(...), '') 转空字符串
  • 去重加 DISTINCTGROUP_CONCAT(DISTINCT r.role_name),避免中间表脏数据导致重复

中间表结构是否规范、外键是否建索引、JOIN 顺序是否符合驱动表选择逻辑——这些细节比语法本身更容易让查询变慢或出错。

text=ZqhQzanResources