结论：not exists比not in更可靠，因其不受子查询null值影响，只判断是否存在匹配行；核心是子查询必须正确关联主表字段（如o.user_id = u.id），否则逻辑全错，且需为关联字段建立索引以避免全表扫描。
直接说结论：用 NOT EXISTS 找缺失数据，核心是写对关联条件，且子查询里必须引用主表字段——漏掉这行，结果全错。
为什么 NOT EXISTS 比 NOT IN 更可靠？
因为 NOT IN 遇到子查询结果含 NULL 时，整行判定为 UNKNOWN，直接被过滤掉。比如：SELECT * FROM users WHERE id NOT IN (1, 2, NULL) 永远返回空，哪怕 id = 3 明明不匹配。
NOT EXISTS 完全不care子查询字段是否为 NULL，只看“有没有行返回”。只要子查询没结果，就认为满足条件。
- 子查询字段没加
NOT NULL约束？NOT IN就不可信 - 想排除外键为空的记录？
NOT EXISTS自动跳过，不用额外WHERE xxx IS NOT NULL - MySQL 8.0+ 对
NOT EXISTS的相关子查询优化已很成熟，性能通常优于NOT IN
NOT EXISTS 子查询里必须写关联条件
常见错误是子查询写成独立查询，比如：SELECT u.id FROM users u WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.user_id = 999) —— 这会把所有用户都排除掉，因为子查询恒真或恒假，和 u 无关。
正确写法必须让子查询“感知”主表当前行，靠 WHERE 中的等值关联实现：
- 主表别名（如
u）要出现在子查询WHERE条件里，例如o.user_id = u.id - 这个等式是相关子查询的标志，缺它就是逻辑崩坏
- 别用
SELECT *，用SELECT 1即可，语义清晰、开销最小
什么时候该用 LEFT JOIN + IS NULL 替代？
当你要查的字段来自两个表，且需要保留主表所有列、同时显示子表缺失细节时，LEFT JOIN 更直观。但 NOT EXISTS 在纯存在性判断上更轻量。
-
NOT EXISTS只关心“有无”，引擎可能提前终止扫描；LEFT JOIN会实际连接并生成中间结果，内存/IO 开销略高 - 如果子表很大，且关联字段没索引，
NOT EXISTS的性能瓶颈几乎总在子查询扫描上——这时必须给o.user_id加索引 -
NOT EXISTS无法直接取子表字段（如订单金额），而LEFT JOIN可以，这是关键取舍点
最易被忽略的是关联字段索引。没索引时，NOT EXISTS 会触发子表全表扫描，每查主表一行就扫一次子表——数据量一上去，秒变慢查询。
