NOT IN 总触发全表扫描是因为子查询含NULL时条件判为UNKNOWN，导致SQL Server退化为依赖子查询模式；改用NOT EXISTS需满足索引、非NULL条件和SELECT 1三前提；LEFT JOIN+IS NULL更适用于复杂右表匹配逻辑；右表必须建立user_id在前的复合索引。
NOT IN 为什么总触发全表扫描？
因为 NOT IN 遇到子查询结果含 NULL 时，整个条件直接判为 UNKNOWN，最终不返回任何行——SQL Server 无法安全物化这个子查询，只能退回到“对主表每行都执行一次子查询”的依赖模式。执行计划里会明确显示 DEPENDENT SUBQUERY，且子查询部分的 rows 预估数常远高于实际，说明它反复扫描右表。
EXISTS 替代 NOT IN 的三个硬性前提
盲目把 NOT IN 改成 NOT EXISTS 不一定快，必须同时满足：
- 子查询的关联字段（如
o.user_id = u.id）上要有索引，否则仍是嵌套循环 + 全表扫描 - 子查询 WHERE 条件不能含
NULL安全陷阱（比如WHERE status IS NOT NULL要显式写出来） -
SELECT列必须简化为SELECT 1，避免优化器误判需取字段值而放弃短路判断
LEFT JOIN + IS NULL 比 NOT EXISTS 更稳的场景
当你要保留主表所有行、且右表匹配逻辑较复杂（比如带时间范围、多条件组合）时，LEFT JOIN 更可控：
原始写法：WHERE u.id NOT IN (SELECT user_id FROM logs WHERE event_time > DATEADD(day, -7, GETDATE()))
改写后：LEFT JOIN logs l ON u.id = l.user_id AND l.event_time > DATEADD(day, -7, GETDATE())WHERE l.user_id IS NULL
注意：时间条件必须写在 ON 子句，不能挪到 WHERE，否则就变成 INNER JOIN，语义全错。
最容易被忽略的索引细节
即使你用了 NOT EXISTS 或 LEFT JOIN，如果右表缺少复合索引，性能依然拉胯。例如：logs(user_id, event_time) 这个顺序不能颠倒——user_id 必须是第一列，否则 JOIN 或 EXISTS 无法高效定位用户记录。没有这个索引，SQL Server 只能先扫全表再过滤，所有改写都白搭。
