不能直接JOIN两张业务表实现多对多，因为user和role表间无外键，强行JOIN会导致笛卡尔积或漏数据；必须通过中间表user_role承载关联，其需含user_id和role_id联合主键，并建对应联合索引以支撑高效查询。
为什么不能直接 JOIN 两张业务表实现多对多？
因为关系不存在——user 和 role 表之间没有外键，强行 JOIN 会笛卡尔爆炸或漏数据。数据库不支持“一个用户对应多个角色”这种语义直接落在两表字段上，必须靠第三张表承载关联事实。
常见错误现象：SELECT * FROM user u JOIN role r ON u.id = r.user_id（r.user_id 根本不存在），或者把 role_ids 存成逗号字符串再用 LIKE 模糊匹配——查不准、索引失效、无法原子更新。
- 中间表（如
user_role）必须有且仅有两个外键：user_id和role_id - 联合主键或唯一索引必不可少，否则同一对关系可能重复插入
- 别在中间表里加业务字段（比如“生效时间”），那是冗余；真有需要，就升级为带属性的关联表，但名字就不再是纯中间表了
LEFT JOIN 中间表后怎么避免重复行？
用户有 3 个角色，user LEFT JOIN user_role 就会返回 3 行相同用户数据——这不是 bug，是关系代数的自然结果。关键看你要什么：要用户+角色列表，还是用户+角色数量，或是用户+所有角色名拼接。
使用场景决定写法：
- 查“每个用户及其所有角色名”：用
LEFT JOIN user_role ur ON u.id = ur.user_id+LEFT JOIN role r ON ur.role_id = r.id，接受多行 - 查“每个用户有几个角色”：用
COUNT(r.id)+GROUP BY u.id，必须配GROUP BY，否则聚合结果错乱 - 查“每个用户的角色名合并在一列”：用
STRING_AGG(r.name, ', ')（PostgreSQL）或GROUP_CONCAT(r.name)（MySQL），同样依赖GROUP BY
WHERE 条件写在 ON 还是 WHERE 里？
差别极大。中间表参与 LEFT JOIN 时，过滤条件位置直接决定是否丢失“没角色的用户”。
比如想查“所有用户，但只显示角色名为 ‘admin’ 的关联”：
- 错：把
r.name = 'admin'写在WHERE—— 会把没角色的用户全过滤掉，变成INNER JOIN效果 - 对：写在
ON里：LEFT JOIN role r ON ur.role_id = r.id AND r.name = 'admin'，才能保留空角色用户 - 性能提示：带条件的
ON不影响索引使用，但WHERE后加函数（如UPPER(r.name) = 'ADMIN'）会让索引失效
中间表查询慢，哪些索引能真正起作用？
单列索引基本没用。中间表高频查询模式就两种：查某用户的所有角色（WHERE user_id = ?），或查某角色的所有用户（WHERE role_id = ?）。这两者都需要覆盖索引支撑。
- 必须建联合索引：
CREATE INDEX idx_user_role_on_user ON user_role(user_id, role_id) - 如果反向查询多，再加一个：
CREATE INDEX idx_user_role_on_role ON user_role(role_id, user_id) - 别只建
(user_id)单列索引——它无法加速JOIN role时的role_id查找 - 注意：主键
(user_id, role_id)默认已有索引，但如果查询只用role_id，这个主键索引无法跳过前导列，仍需额外索引
复杂点在于：中间表的数据分布极不均匀（比如超级管理员关联几千个角色），这时即使有索引，JOIN 的执行计划也可能退化。得看 EXPLAIN 里是不是走了 Index Nested Loop，而不是 Hash Join 或更糟的 Materialize。
