正确：中间表必须包含两个外键字段，分别指向双方主键，以实现多对多关系的完整、准确关联。
中间表结构必须包含两个外键字段
多对多关系不能直接用两个主表字段建立关联，必须通过中间表（也叫关联表、junction table）桥接。这个中间表至少要有两个外键字段，分别指向两边主表的主键。比如 users 和 roles 是多对多，中间表 user_roles 就得有 user_id 和 role_id 两列，且各自加外键约束。漏掉任一外键或没建索引，JOIN 时容易全表扫描甚至查出重复/缺失数据。
常见错误现象：SELECT * FROM users JOIN user_roles ON users.id = user_roles.user_id 只连了一边，结果里每个用户会重复出现多次（取决于该用户有多少角色），但看不到角色名——因为还没 JOIN roles 表。
- 中间表命名建议用复数+下划线组合，如
products_categories，别用product_category_map这类模糊名 -
user_id和role_id字段类型必须和对应主表主键完全一致（包括是否为UNSIGNED、字符集、排序规则） - 务必给这两个外键字段分别建索引，否则大表 JOIN 性能急剧下降
三表 JOIN 顺序和 ON 条件要严格对应
查用户及其所有角色名，得写三个表的 JOIN：先连中间表，再连另一边主表。ON 条件必须一级级“顺藤摸瓜”，不能跳步。正确写法是：users JOIN user_roles ON users.id = user_roles.user_id JOIN roles ON user_roles.role_id = roles.id。如果写成 users JOIN roles ON users.id = roles.id，就完全错乱了——这是拿用户 ID 去匹配角色 ID，逻辑崩坏。
使用场景：后台权限列表页需要展示“张三 — 管理员, 编辑”，就得靠这种三表 JOIN 拼出完整信息。若只查某几个字段，记得用表别名避免歧义，比如 SELECT u.name, r.name AS role_name。
- LEFT JOIN 要慎用：如果用
LEFT JOIN user_roles再LEFT JOIN roles，用户没分配角色时会显示NULL角色名，但若业务要求只显示已分配角色的用户，就该用 INNER JOIN - MySQL 8.0+ 支持自然连接（NATURAL JOIN），但中间表字段名若和主表不完全一致（比如主表叫
id，中间表叫user_id），它会失效甚至报错，别图省事
GROUP_CONCAT 配合 JOIN 解决一对多聚合显示
上面三表 JOIN 后，一个用户有多条记录（每条对应一个角色）。如果前端只要一行显示“张三 — 管理员, 编辑”，就得用 GROUP_CONCAT 聚合。关键点在于：必须加 GROUP BY users.id，否则聚合函数会把全表所有角色拼一起。
示例语句：SELECT u.name, GROUP_CONCAT(r.name SEPARATOR ', ') AS roles 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。注意 SEPARATOR 可自定义分隔符，不写默认逗号加空格。
- 如果角色名含逗号或特殊字符，
GROUP_CONCAT默认不转义，前端解析可能出错；可配合REPLACE(r.name, ',', '，')预处理 -
GROUP_CONCAT有长度限制（默认 1024 字符），超长会被截断，需调大group_concat_max_len参数 - PostgreSQL 用
STRING_AGG(r.name, ', ')，SQLite 用GROUP_CONCAT(r.name, ', ')，函数名不同但逻辑一致
WHERE 条件写在 JOIN 之后，别放 ON 里滥用
想查“所有管理员用户”，条件 r.name = 'admin' 必须放在 WHERE 子句，而不是第二个 ON 里。如果写成 JOIN roles r ON ur.role_id = r.id AND r.name = 'admin'，会导致 LEFT JOIN 语义改变，且当用 INNER JOIN 时看似结果一样，但可读性和维护性极差。
真正容易踩的坑是：在多表 JOIN 中，把本该过滤结果集的条件误塞进 ON，尤其涉及中间表字段时（比如 ur.status = 'active'）。这类状态字段属于中间表自身属性，放 ON 更合理；但角色名、用户名这类主表字段，一律归 WHERE 管。
- EXPLAIN 执行计划里，如果发现
type是ALL（全表扫描），大概率是 WHERE 条件没落到有索引的字段上，或者 JOIN 顺序导致驱动表选错 - 中间表如果有软删除字段（如
deleted_at），查询时务必在 WHERE 加ur.deleted_at IS NULL，否则逻辑删除的数据仍会参与 JOIN
实际写的时候，先画个三张表的字段草图，标清楚外键指向，再动笔写 JOIN。中间表看着简单，但字段类型不一致、索引缺失、条件位置错乱，这三处最容易让结果对不上预期。
