NOT EXISTS 更优，因其语义清晰、自动处理NULL、支持短路终止，且避免LEFT JOIN的笛卡尔膨胀和IS NULL误判；需确保子查询含相关条件并建立索引。
为什么用 NOT EXISTS 而不是 LEFT JOIN ... IS NULL
直接结论：在客户表（customers）远大于订单表（orders）时，NOT EXISTS 通常更快，且语义更清晰——它明确表达“对每个客户，检查是否存在匹配订单”，而不会因 LEFT JOIN 产生中间笛卡尔膨胀或重复行干扰判断。
常见错误是写成 NOT IN (SELECT customer_id FROM orders)，一旦 orders.customer_id 含 NULL，整个查询结果为空——这是 SQL 三值逻辑的坑，必须避开。
-
NOT EXISTS自动忽略子查询中的NULL，安全可靠 - 子查询中只需
SELECT 1，无需实际字段，数据库优化器能更好剪枝 - 确保
orders.customer_id有索引，否则性能会断崖式下跌
NOT EXISTS 子查询的标准写法与关键细节
核心结构是外层查客户，内层用相关子查询验证订单是否存在。重点在于相关条件（c.id = o.customer_id）必须写在子查询的 WHERE 中，不能漏掉。
SELECT c.id, c.name FROM customers c WHERE NOT EXISTS ( SELECT 1 FROM orders o WHERE o.customer_id = c.id );
- 子查询里用
SELECT 1，不是SELECT *或具体字段——减少数据搬运开销 - 别名
c和o必须在外层和子查询中一致，否则报错Unknown column 'c.id' in 'where clause' - 如果客户表主键不是
id，而是customer_id，记得同步替换所有引用
当客户表有软删除字段时怎么处理
真实业务中，customers 表常带 is_deleted 或 status 字段。若不加过滤，已软删除的客户也会被查出来，误判为“从未下单”。
- 必须在外层
WHERE加上状态过滤，例如WHERE c.is_deleted = 0 - 不要把状态条件塞进子查询——那会改变语义，变成“查未被删除且没下单的客户”，但子查询本不该管客户是否删除
- 如果订单表也有软删除（如
orders.status = 'cancelled'不算有效订单），则子查询的WHERE需补充AND o.status = 'completed'
MySQL 8.0+ 与 PostgreSQL 的执行差异提醒
两者都支持标准写法，但优化器行为不同：MySQL 在某些版本中对 NOT EXISTS 的索引下推不够激进，PostgreSQL 则通常更早放弃扫描。若发现慢，先看执行计划。
- MySQL：用
EXPLAIN FORMAT=TREE确认是否走了orders.customer_id索引 - PostgreSQL：用
EXPLAIN ANALYZE观察是否出现Subquery Scan嵌套过深 - 若客户数超百万且订单稀疏，考虑建覆盖索引：
CREATE INDEX idx_orders_cid_status ON orders(customer_id) WHERE status = 'completed';（PostgreSQL 支持条件索引）
最易被忽略的是子查询里漏写相关条件，导致变成非相关子查询——结果变成“只要订单表有任意一条记录，就全不返回”，静默出错，查不出任何客户。
