中间表必须显式出现在JOIN链中，不能仅藏于WHERE子句；否则无法准确表达多对多交集逻辑，且无法利用联合索引加速查询。
中间表必须出现在FROM或JOIN链中，不能只藏在WHERE里
多对多关系的语义核心是“某用户同时关联多个角色”，但WHERE id IN (SELECT ...)这类写法把中间表当工具用，实际执行时每个子查询独立运行，无法表达“同一行数据需满足多个条件”的逻辑。比如查“同时有角色1和角色2的用户”，IN会返回所有满足任一条件的用户ID，而非交集。
正确做法是让中间表作为显式参与者：用JOIN把它拉进查询主干。这样数据库引擎才能基于连接路径做准确匹配，也能利用索引加速（前提是user_role表上建了(user_id, role_id)联合索引）。
- 错误示范：
SELECT * FROM users WHERE id IN (SELECT user_id FROM user_role WHERE role_id = 1) AND id IN (SELECT user_id FROM user_role WHERE role_id = 2) - 正确起点：
SELECT u.* FROM users u JOIN user_role ur1 ON u.id = ur1.user_id JOIN user_role ur2 ON u.id = ur2.user_id WHERE ur1.role_id = 1 AND ur2.role_id = 2 - 更推荐用
GROUP BY + HAVING替代自连接，尤其当角色数动态变化时：SELECT u.* FROM users u JOIN user_role ur ON u.id = ur.user_id WHERE ur.role_id IN (1, 2) GROUP BY u.id HAVING COUNT(DISTINCT ur.role_id) = 2
LEFT JOIN中间表时，WHERE条件别误杀主表记录
如果业务需要列出“所有用户及其角色信息（含无角色者）”，自然要用LEFT JOIN。但很多人把过滤条件写在WHERE里，比如WHERE ur.role_id = 1，结果发现没角色的用户全没了——因为WHERE是在连接完成后才执行，会把ur.role_id为NULL的行直接剔除。
要保留主表全部记录，过滤逻辑必须下沉到ON子句：LEFT JOIN user_role ur ON u.id = ur.user_id AND ur.role_id = 1。这样即使某用户没角色1，ur.*字段仍为NULL，但用户本身还在结果集中。
- 常见陷阱：
LEFT JOIN user_role ur ON u.id = ur.user_id WHERE ur.role_id = 1→ 实际变成INNER JOIN - 安全写法：
LEFT JOIN user_role ur ON u.id = ur.user_id AND ur.role_id = 1 - 若需查“有角色1的用户+其部门信息”，部门表也得用
LEFT JOIN并把部门条件放ON里，否则同样漏数据
MySQL UPDATE多表时，JOIN位置和语法不能错
MySQL支持UPDATE ... JOIN语法批量更新，但JOIN必须紧跟UPDATE关键字之后，且不能带FROM。写成UPDATE t1 FROM t1 JOIN t2 ON ... SET ...会直接报错ERROR 1064。
被更新的表名必须明确写出（不能只用别名），且JOIN顺序影响结果：先JOIN的表决定驱动方向，小表作左表更高效。更新前务必用SELECT验证匹配行数，避免误更新。
- 正确：
UPDATE orders o JOIN customers c ON o.customer_id = c.id SET o.status = 'shipped' WHERE c.country = 'CN' - 错误：
UPDATE orders o FROM orders o JOIN customers c ON o.customer_id = c.id SET ... - 危险操作：
UPDATE orders SET status = 'shipped' JOIN customers ...（缺少目标表名，语法非法）
SQL Server和PostgreSQL处理中间表关联的语法差异
SQL Server不认UPDATE ... JOIN，硬写会报Incorrect syntax near the keyword 'JOIN'；PostgreSQL则用UPDATE ... FROM实现类似效果。三者的中间表关联逻辑一致，但语法壳不同。
SQL Server必须用MERGE，且WHEN MATCHED分支不可省略；PostgreSQL的FROM子句允许直接引用关联表字段；MySQL最直白，但仅限UPDATE语句。跨数据库迁移时，中间表的JOIN写法容易成为兼容性雷区。
- SQL Server：
MERGE orders AS t USING (SELECT ...) AS s ON t.id = s.id WHEN MATCHED THEN UPDATE SET t.status = s.new_status; - PostgreSQL：
UPDATE orders SET status = s.new_status FROM (SELECT ...) AS s WHERE orders.id = s.id; - MySQL：
UPDATE orders o JOIN (SELECT ...) AS s ON o.id = s.id SET o.status = s.new_status;
中间表不是辅助工具，它是多对多关系的实体承载者。它的字段参与连接、过滤、分组，每一步都影响语义准确性。最容易被忽略的是：JOIN顺序决定结果集范围，ON里的条件决定关联精度，而WHERE里的条件可能悄悄把本该保留的记录删掉。
