NOT EXISTS可安全替代NOT IN处理NULL问题，因其不依赖值比较而只判断行存在性；必须写成相关子查询（如WHERE t2.id = t1.ref_id），且子查询中SELECT 1更高效；LEFT JOIN + IS NULL是直观替代方案。
用 NOT EXISTS 替代 NOT IN 处理 NULL 值问题
直接用 NOT IN 很容易漏掉结果，尤其当子查询返回 NULL 时，整个条件会变成 UNKNOWN，导致整行被过滤掉——这不是你想要的“排除不存在记录”，而是“意外丢数据”。NOT EXISTS 没这个问题，它只关心是否存在匹配行，不碰 NULL 语义。
-
NOT IN要求子查询列严格非空，否则结果为空集；NOT EXISTS不依赖值比较，只做关联存在性判断 - 写法上，
NOT EXISTS必须带相关子查询（correlated subquery），即子查询里要引用外部表字段，比如WHERE t2.id = t1.ref_id - 性能通常更好，尤其在子表有合适索引时，数据库能用半连接（semi-join）优化
LEFT JOIN + IS NULL 是更直观的替代方案
如果你不习惯嵌套子查询，用 LEFT JOIN 显式关联再筛空值，逻辑更直白，也更容易加调试条件。
- 写法：先
LEFT JOIN目标表，然后WHERE joined_table.pk IS NULL - 注意别漏掉
IS NULL的括号和空格，写成ISNULL()（SQL Server 函数）或IS NULL（标准 SQL）效果完全不同 - 如果关联字段可能为
NULL，确保ON条件里没隐含NULL比较，否则LEFT JOIN会多出意外匹配行
子查询必须去重或限制字段，避免意外多行报错
某些数据库（如 MySQL 5.7 严格模式、PostgreSQL）在子查询返回多列或多行时，会对 IN 或标量子查询直接报错。即使语法通过，逻辑也可能出错。
- 用于
IN或=的子查询，必须是单列、单值（或明确用ANY/SOME支持多值） - 用
EXISTS或NOT EXISTS时，子查询 SELECT 列无关紧要，写SELECT 1或SELECT NULL都行，但别写*—— 无谓增加解析开销 - 如果子查询本身含聚合或窗口函数，确认是否需要
GROUP BY，否则可能因隐式分组行为导致结果不可预期
WHERE 条件写在子查询内还是外，影响结果和性能
把过滤条件放在子查询内部（比如 SELECT id FROM blacklist WHERE status = 'active'），比放在外部 WHERE 中更安全、更快。
- 子查询内过滤能减少中间结果集大小，尤其对大表；放外面等于先全量关联再筛，浪费 I/O 和内存
- 如果子查询条件依赖主查询字段（如时间范围随主表某字段变化），必须用相关子查询，不能提前固化子查询结果
- MySQL 8.0+ 支持物化 CTE，但默认仍按需执行；PostgreSQL 的
MATERIALIZEDCTE 也得显式声明，别假设数据库会自动优化
NOT EXISTS 或 LEFT JOIN ... IS NULL，别碰 NOT IN；子查询字段、NULL 处理、条件位置这三点，任一出错都会让“排除不存在”变成“排除了一半”或者“一条没排除”。 
