不能直接在WHERE中嵌套查多对多，因为IN或=等子查询无法保证同一用户在多个独立子查询中均存在，无法表达“同时满足多个中间表条件”的逻辑；必须通过JOIN显式引入中间表，并用GROUP BY + HAVING或自连接实现准确语义。

直接用嵌套查询处理多对多关系容易出错——因为中间表没显式参与，WHERE 子句里的子查询常会漏掉关联路径，导致结果为空或重复。

为什么不能直接在 WHERE 中嵌套查多对多？

多对多必须经由中间表（如 user_role）桥接，而 IN 或 = 类子查询无法表达“一个用户对应多个角色，且需同时满足多个条件”这种逻辑。比如想查“既是管理员又是编辑的用户”，写成：

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);

看似合理，但实际执行时，两个子查询各自独立，不保证同一 user_id 在两条记录中都存在。更糟的是，若中间表没索引，性能会急剧下降。

用 JOIN 显式连接中间表才是正解

把中间表当作一等公民参与连接，才能准确建模多对多语义。关键点是：中间表必须出现在 FROM 或 JOIN 链中，不能只藏在 WHERE 里。

• 查“有角色的用户”：SELECT u.* FROM users u JOIN user_role ur ON u.id = ur.user_id
• 查“同时拥有角色 1 和 2 的用户”：必须自连接中间表，或用 GROUP BY + HAVING COUNT(DISTINCT ...)
• 查“用户及其所有角色名”：SELECT u.name, r.name FROM users u JOIN user_role ur ON u.id = ur.user_id JOIN roles r ON ur.role_id = r.id

需要“且”逻辑时，避免嵌套，改用分组聚合

嵌套子查询难以表达“同时满足多个中间表条件”，这时 GROUP BY + HAVING 更可靠、更易读。

例如查“既是管理员（role_id=1）又是编辑（role_id=2）的用户”：

SELECT u.id, u.name
FROM users u
JOIN user_role ur ON u.id = ur.user_id
WHERE ur.role_id IN (1, 2)
GROUP BY u.id, u.name
HAVING COUNT(DISTINCT ur.role_id) = 2;

这个写法明确表达了“同一个用户，在中间表中至少有两条匹配记录，且角色 ID 不同”。比嵌套两层 IN 更健壮，也更容易加索引优化（如在 (user_id, role_id) 上建联合索引）。

CTE 可读性高，但别为了嵌套而嵌套

如果业务逻辑确实复杂（比如要先筛出某类角色用户，再关联其订单，再统计），CTE 是好选择；但前提是每层 CTE 都有明确的中间语义，且中间表仍被显式 JOIN。

错误示范（把中间表又藏进子查询）：

WITH admin_users AS (
  SELECT id FROM users WHERE id IN (SELECT user_id FROM user_role WHERE role_id = 1)
)
SELECT * FROM admin_users au JOIN orders o ON au.id = o.user_id;

正确做法是让 user_role 出现在 CTE 的 FROM 中：

WITH admin_users AS (
  SELECT DISTINCT u.id, u.name
  FROM users u
  JOIN user_role ur ON u.id = ur.user_id
  WHERE ur.role_id = 1
)
SELECT au.*, o.amount
FROM admin_users au
JOIN orders o ON au.id = o.user_id;

真正容易被忽略的点是：多对多不是“能不能嵌套”的问题，而是“中间表是否被当作数据实体参与连接”的问题。只要中间表没在 JOIN 链里露面，任何嵌套都只是掩耳盗铃。