用 not exists + 反向否定最可靠：它语义清晰、天然处理空集与null、避免count误判和all的标量陷阱，且性能更优。
直接说结论：用 NOT EXISTS + 反向否定，比用 ALL 或嵌套 COUNT 更可靠、更易读、也更少踩坑。
为什么不要用 COUNT() = (子查询返回行数) 判断“全部满足”
这种写法看似直观，但逻辑脆弱：
- 如果子查询结果为空（比如关联表没数据），
COUNT()返回 0，而外层条件可能误判为“全满足”，实际是“无约束” - 若主表某条记录在子查询中本应匹配 3 行，但因 JOIN 条件漏掉 1 行（比如 NULL 值未处理），
COUNT()变成 2，就错误排除该记录 - 必须额外确保子查询与主表的关联字段非 NULL，否则
JOIN会丢行，COUNT失真 - 性能上，
COUNT(*)往往触发全扫描，尤其没索引时，比半途退出的NOT EXISTS慢得多
ALL 的语义陷阱：它只适用于标量比较，不是“全匹配”
ALL 看起来像“全部”，但它实际作用是：把左侧表达式跟子查询返回的**每个标量值**逐个比较，全部成立才返回真。它不关心“是否覆盖了所有目标项”。
典型误用场景：
SELECT user_id FROM orders o WHERE 100 >= ALL ( SELECT amount FROM payments p WHERE p.order_id = o.id );
这段代码意思是：“该订单所有付款金额都不超过 100”，不是“该订单的每笔付款都已录入且均 ≤100”。如果某笔付款漏录（子查询没查到），ALL 会返回 TRUE（空集下 ALL 默认为真），造成逻辑漏洞。
所以：ALL 适合“最大值约束”类判断，不适合“完整性校验”。
正确解法：用 NOT EXISTS 表达“不存在不满足的项”
这是 SQL 中表达“全部满足”的标准模式，语义清晰、行为确定、兼容所有主流数据库。
例如：查出“所有订单状态都为 'shipped' 的用户”
SELECT DISTINCT u.id, u.name
FROM users u
WHERE NOT EXISTS (
SELECT 1 FROM orders o
WHERE o.user_id = u.id
AND o.status != 'shipped'
);
关键点：
- 子查询查的是“反例”——即不满足条件的记录
-
NOT EXISTS成立，意味着找不到任何反例 → 所有都满足 - 即使某用户没有订单（子查询返回空），
NOT EXISTS仍为TRUE，符合“无违规即合规”的业务直觉 - 可天然处理
NULL：只要o.status是NULL，o.status != 'shipped'就为UNKNOWN，不会被忽略
容易被忽略的细节：关联字段 NULL 会导致 NOT EXISTS 失效吗？
不会，但要注意写法。下面这个是错的：
WHERE NOT EXISTS ( SELECT 1 FROM orders o WHERE o.user_id = u.id -- 若 u.id 是 NULL，整个条件为 UNKNOWN，NOT EXISTS 返回 FALSE );
如果 u.id 可能为 NULL（比如来自 LEFT JOIN 结果），需显式过滤：
WHERE u.id IS NOT NULL
AND NOT EXISTS (
SELECT 1 FROM orders o
WHERE o.user_id = u.id AND o.status != 'shipped'
);
这才是真正健壮的写法。多数情况下，主表 ID 不会为 NULL，但一旦涉及多层 JOIN 或 UNION，这点极易遗漏。
