NOT IN 遇到 NULL 时失效，因三值逻辑返回 UNKNOWN，被 WHERE 当作不匹配，导致“一条都没删”；正确做法是用 NOT EXISTS 或在子查询中加 IS NOT NULL。
NOT IN 遇到 NULL 时为什么直接失效
这是最常被忽略的底层逻辑：只要子查询结果中任意一行的字段值为 NULL，整个 NOT IN 表达式就会返回 UNKNOWN，而 SQL 的 WHERE 子句只接受 TRUE 的行——UNKNOWN 被当作不匹配，等效于“全都不删”。但更危险的是，很多人误以为它“删了部分”，其实是“一条都没删”，而自己没察觉。
典型触发场景：
- 子查询来自左连接（
LEFT JOIN）后取右表字段，右表无匹配时该字段为NULL - 子查询字段允许为
NULL，且数据中确实存在NULL值（比如user_id字段有空值） - 用
SELECT col FROM t WHERE ...作为子查询，但未加WHERE col IS NOT NULL
用 NOT EXISTS 替代 NOT IN 的实操写法
NOT EXISTS 不受 NULL 影响，语义清晰：只要子查询查不到匹配行，外层就保留。它也是标准 SQL，兼容性好，执行计划通常也更优。
错误写法（危险）：
DELETE FROM orders WHERE customer_id NOT IN ( SELECT id FROM customers WHERE status = 'active' );
正确写法（推荐）：
DELETE FROM orders o WHERE NOT EXISTS ( SELECT 1 FROM customers c WHERE c.id = o.customer_id AND c.status = 'active' );
关键点：
- 子查询必须关联外层表（如
c.id = o.customer_id），否则变成全表扫描或语义错误 - 把过滤条件（如
c.status = 'active'）放在子查询内部，而不是外部WHERE，避免漏掉关联逻辑 - 子查询里用
SELECT 1即可，无需查具体字段，减少开销
如果坚持用 NOT IN，必须显式排除 NULL
不是不能用，而是必须主动防御。只要子查询可能返回 NULL，就必须在 IN 前筛掉它。
安全写法示例：
DELETE FROM orders WHERE customer_id NOT IN ( SELECT id FROM customers WHERE status = 'active' AND id IS NOT NULL );
注意：
-
AND id IS NOT NULL必须加在子查询里，不能加在外层（WHERE customer_id IS NOT NULL AND customer_id NOT IN (...)无效） - 如果子查询涉及多字段或复杂表达式，要检查每一个参与比较的字段是否可能为
NULL - MySQL 8.0+ 对
NOT IN有部分优化，但行为仍遵循三值逻辑，不可依赖
删除前务必先用 SELECT 验证逻辑
任何带子查询的 DELETE 操作，都应先改写成 SELECT 确认影响范围。这是防误删的铁律。
例如，把上面的 NOT EXISTS 删除语句，先跑：
SELECT * FROM orders o WHERE NOT EXISTS ( SELECT 1 FROM customers c WHERE c.id = o.customer_id AND c.status = 'active' );
再确认结果集是否符合预期。尤其注意：
- 检查返回行数是否合理（比如突然返回上万行，大概率逻辑有误）
- 抽样几条记录，手工验证子查询是否真没匹配上（比如查一个
customer_id在customers表里是否存在且状态是否为'active'） - 生产环境建议在事务中执行：
BEGIN; DELETE ...; SELECT ROW_COUNT(); ROLLBACK;（或COMMIT）
真正容易出问题的，从来不是语法写错，而是忘了子查询里藏着一个 NULL，或者没验证就直接删。哪怕加了 IS NOT NULL，也要看它加的位置对不对；用 NOT EXISTS 也得确保关联条件写准了。删库跑路往往始于一次没验证的 NOT IN。
