多层嵌套子查询不适合多对多关系校验，因其无法保证同一主键在多个子查询中同时存在，易因null、重复或缺失索引导致结果错误；应使用join+group by+having count(distinct)=n，或双重not exists确保精确匹配。
多层嵌套子查询不适合做多对多关系校验——它既无法表达“同时满足多个中间条件”的语义，又容易因 NULL、重复、索引缺失导致结果错误或性能崩溃。真正可用的方案是显式 JOIN + GROUP BY + HAVING，或双重 NOT EXISTS。
WHERE IN 嵌套两层就失效
比如查“同时拥有角色 1 和 2 的用户”，写成：
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 是同一行记录。若某用户只在其中一张中间表里有记录（比如因数据同步延迟或脏写），就会被误判为匹配。
- 子查询之间无上下文绑定，无法约束“同一个
user_id必须在两张子查询结果中都出现” - 若
user_role表没在(user_id, role_id)上建联合索引，两个子查询都会走全表扫描 - 一旦子查询返回 NULL（比如中间表字段允许 NULL），整个
IN条件变成 UNKNOWN，该行直接被过滤
GROUP BY + HAVING COUNT(DISTINCT) 是最稳路径
必须把中间表显式拉进 JOIN 链，再以主表 ID 分组，统计匹配的目标值数量：
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 不同”。关键点：
-
WHERE先粗筛出含任一目标角色的记录，减少分组基数 -
GROUP BY必须包含所有非聚合字段（如u.name），否则 MySQL 8.0+ 会报 ERROR 1055 -
COUNT(DISTINCT ur.role_id)防止同一角色重复插入导致计数虚高 - 联合索引
(user_id, role_id)能让 WHERE + GROUP BY 都走索引，避免临时表和文件排序
需要“完全匹配”（不多不少）时用双重 NOT EXISTS
如果业务要求“恰好拥有 a、b、c 三项，不能多也不能少”，HAVING COUNT = 3 只校验下限，会漏掉含冗余项（如还有 d）的记录。此时必须用双重否定：
SELECT DISTINCT c1.taskid FROM CHECKITEM c1 WHERE NOT EXISTS ( SELECT 1 FROM (SELECT 'a' AS code UNION ALL SELECT 'b' UNION ALL SELECT 'c') t WHERE NOT EXISTS ( SELECT 1 FROM CHECKITEM c2 WHERE c2.taskid = c1.taskid AND c2.cheitcode = t.code ) ) AND NOT EXISTS ( SELECT 1 FROM CHECKITEM c3 WHERE c3.taskid = c1.taskid AND c3.cheitcode NOT IN ('a','b','c') );
第一层 NOT EXISTS 拦截缺失项，第二层拦截冗余项。注意：
- 内层用
UNION ALL构造目标集合，比硬编码更易维护 - 外层
SELECT DISTINCT是必须的，因为中间表可能有重复taskid - 若目标列表动态生成（如来自应用参数），需拼 SQL 或改用 MySQL 8.0+ 的
VALUES ROW('a'), ROW('b')
复杂点永远不在语法嵌套深度，而在数据边界：中间表是否有重复、是否含 NULL、外键是否真被约束、索引是否覆盖查询路径。别先写子查询，先看 EXPLAIN 输出里的 rows 和 Extra 字段——如果出现 Using temporary; Using filesort，说明当前写法已经不可靠了。
