EXISTS与NOT EXISTS用于存在性判断：EXISTS检查子查询是否返回至少一行，有则返回TRUE；NOT EXISTS检查子查询是否无返回，无则返回TRUE；二者均支持短路执行、天然规避NULL陷阱，且需配合关联字段索引以保障性能。
用 EXISTS + NOT EXISTS 实现“订购了所有指定产品”的逻辑
直接用 IN 或 JOIN 无法表达“全部满足”，必须转化为“不存在未订购的指定产品”。核心思路是：对每个客户，检查是否存在某个指定产品他没买过；若一个都不存在，说明他全买了。
假设表结构：orders（含 customer_id, product_id），products_to_check 是你要验证的指定产品列表（可用 VALUES 或临时表）。
- 先明确指定产品集合——建议建临时表或用
WITH子句定义，避免硬编码导致维护困难 - 外层查
customer_id，内层用NOT EXISTS检查该客户是否“缺”某个指定产品 - 注意
NOT EXISTS的子查询里必须关联客户，否则变成全局判断，结果恒为假
常见错误：用 COUNT 比较数量会漏掉重复订购场景
比如客户 A 订了产品 P1 三次、P2 一次，而指定产品是 {P1, P2} —— 表面看 COUNT(DISTINCT product_id) = 2 成立，但若误用 COUNT(*) 就可能因重复行数不等而误判。更危险的是，如果客户只订了 P1 两次，COUNT(*) 算出 2，也会错判为“全订”。
- 永远用
COUNT(DISTINCT product_id)而非COUNT(*)做数量对比 - 即使数量相等，也不代表覆盖了全部指定产品（比如他订了 P1 和 P3，但你要查的是 P1/P2）——所以纯 COUNT 方案本质不可靠
- 只有结合
GROUP BY customer_id+HAVING COUNT(DISTINCT product_id) = (SELECT COUNT(*) FROM products_to_check)且product_id IN (SELECT id FROM products_to_check)才勉强可行，但嵌套深、难调试
性能关键：给 orders(customer_id, product_id) 加联合索引
子查询中频繁按客户查其订购的产品，或按产品查哪些客户买过，没有索引时会触发全表扫描。尤其当 orders 表很大而指定产品较少时，NOT EXISTS 内层查询执行次数 = 客户数 × 指定产品数，放大效应明显。
- 必须建索引：
CREATE INDEX idx_cust_prod ON orders(customer_id, product_id) - 如果常反向查“某产品被哪些客户订购”，再加一个
(product_id, customer_id)索引 - PostgreSQL 中可考虑用
EXISTS配合LATERAL提前终止，MySQL 8.0+ 支持半连接优化，但别依赖——索引仍是底线
兼容性注意：不同数据库对 NULL 和空集的处理差异
如果 products_to_check 为空（比如动态参数没传），某些数据库返回所有客户，有些返回空结果。另外，若某客户在 orders 中无记录，NOT EXISTS 正确排除他；但如果用 LEFT JOIN + IS NULL 写法，NULL 处理稍有不慎就会引入误判。
- 显式检查
products_to_check是否为空，空则直接返回空集或抛错，避免语义歧义 - 确保
orders.product_id非空（加NOT NULL约束），否则product_id IS NULL可能干扰NOT EXISTS判断 - SQLite 对相关子查询优化弱，大数据量下建议改用临时表物化指定产品集
真正卡住人的不是语法，而是把“全部”翻译成“不存在例外”这个思维转换，以及索引缺失导致本地测得快、上线就超时。
