not exists配合否定条件是实现“全部满足”的标准解法,即将“所有子项都满足a”转化为“不存在不满足a的子项”,如select o.id from order o where not exists (select 1 from order_item oi where oi.order_id = o.id and oi.status != 'shipped')。

子查询返回多行时,不能直接用 = 或 IN 判断“全部满足”
很多人一上来就写 WHERE id IN (SELECT parent_id FROM child WHERE status = 'active' AND type = 'A'),结果发现这只能查出“至少有一个子记录满足条件”的父级,而不是“所有子记录都满足”。IN 是“存在性”逻辑,不是“全量约束”逻辑。
真正要表达“某个父级的所有子记录都满足某条件”,本质是**反向思考**:找那些不存在违反条件的子记录的父级。常用手法是用 NOT EXISTS 配合否定条件。
- 错误写法:
WHERE id IN (SELECT parent_id FROM child WHERE status = 'active')→ 只要有一个 active 就入选 - 正确思路:先找出“有任意子记录不满足条件”的父级,再用
NOT EXISTS排除它们 - 示例场景:查所有“子订单全部已发货”的订单(
order表),子表order_item有status字段
NOT EXISTS + 否定条件才是“全满足”的标准解法
核心在于把“全部是 A”转换成“不存在非 A”。比如“所有子项 status = 'shipped'”,等价于“不存在 status != 'shipped' 的子项”。
SELECT o.id, o.name
FROM order o
WHERE NOT EXISTS (
SELECT 1
FROM order_item oi
WHERE oi.order_id = o.id
AND oi.status != 'shipped'
);
-
NOT EXISTS子查询中,oi.status != 'shipped'是关键——它捕获任何“破坏全量条件”的子记录 - 如果某个订单有 10 个子项,其中 1 个是
'pending',这个子查询就会返回一行,导致外层NOT EXISTS为 false,该订单被过滤掉 - 注意:空子记录集(即订单没有子项)也会通过此检查——因为
NOT EXISTS对空集返回 true;若业务要求“必须有子项且全满足”,需额外加EXISTS (SELECT 1 FROM order_item WHERE order_id = o.id)
多个子条件同时要求“全部满足”时,否定逻辑要合并
当需要“所有子记录同时满足 status = 'shipped' 且 warehouse_id IS NOT NULL”,不能分开写两个 NOT EXISTS,而要把两个否定条件用 OR 组合在一个子查询里。
SELECT o.id
FROM order o
WHERE NOT EXISTS (
SELECT 1
FROM order_item oi
WHERE oi.order_id = o.id
AND (oi.status != 'shipped' OR oi.warehouse_id IS NULL)
);
- 错误写法:
AND oi.status != 'shipped'和AND oi.warehouse_id IS NULL用AND连接 → 只排除同时违反两个条件的子项,漏掉只违反其一的情况 - 正确逻辑:
OR表达“只要违反任一条件,就算不满足全量要求” - 性能上,确保
order_item(order_id, status, warehouse_id)有联合索引,否则NOT EXISTS可能全表扫描
聚合 + HAVING 方案适用于可计数的简单场景
如果“全部满足”可以转化为数量对比(例如:子记录总数 == 满足条件的子记录数),也可以用 GROUP BY + HAVING,但仅限于条件可布尔化且无 NULL 干扰的场景。
SELECT o.id FROM order o JOIN order_item oi ON oi.order_id = o.id GROUP BY o.id HAVING COUNT(*) = COUNT(CASE WHEN oi.status = 'shipped' AND oi.warehouse_id IS NOT NULL THEN 1 END);
- 这个写法依赖
COUNT()忽略NULL的特性:COUNT(CASE ...)只统计满足条件的行 - 隐患:如果子表有
NULL值,且条件中用了=而不是IS NULL,容易漏判;NOT EXISTS更直观、更少陷阱 - 无法处理“所有子项值唯一”或“所有子项在某个集合内”这类更复杂的全量约束
真正难的不是写出语法,而是想清楚“全部满足”在逻辑上到底等价于什么——多数人卡在第一步的命题转换上,而不是 SQL 写法本身。











