NOT 运算符在 WHERE 子句中需显式处理 NULL 才不漏数据，因 NOT (column = 'A') 会过滤掉 column 为 NULL 的行；正确写法是 user_level != 'VIP' OR user_level IS NULL。
NOT 运算符在 WHERE 子句中怎么写才不漏数据
直接用 NOT 排除数据时，最常踩的坑是忽略 NULL 值行为——NOT (column = 'A') 不会返回 column 为 NULL 的行，因为 NULL = 'A' 结果是 UNKNOWN，而 NOT UNKNOWN 仍是 UNKNOWN，被 WHERE 过滤掉。
实际场景比如：查“不是 VIP 用户”，但用户等级字段可能为空，这时只写 NOT user_level = 'VIP' 会漏掉所有 user_level IS NULL 的记录。
- 正确写法要显式处理
NULL：user_level != 'VIP' OR user_level IS NULL，或更清晰地：NOT (user_level = 'VIP') OR user_level IS NULL - 如果业务逻辑里
NULL表示“未分级”，且你确实不想包含它，那NOT user_level = 'VIP'是对的——但必须确认这点，不能默认 - 用
IS NOT TRUE（PostgreSQL）或IS NOT FALSE可以绕过三值逻辑，但可读性差，不推荐日常使用
NOT 和 NOT IN 遇到 NULL 会彻底失效
NOT IN 是重灾区。只要子查询或列表里有一个 NULL，整个条件恒为 FALSE 或 UNKNOWN，结果集变空。
例如：SELECT * FROM orders WHERE order_status NOT IN ('shipped', 'cancelled', NULL) —— 这条语句查不到任何数据，哪怕表里有 order_status = 'pending' 的行。
- 根本原因：
'pending' NOT IN ('shipped', 'cancelled', NULL)等价于NOT ('pending' = 'shipped' OR 'pending' = 'cancelled' OR 'pending' = NULL)，最后一项'pending' = NULL是UNKNOWN，整个 OR 表达式变成UNKNOWN，NOT UNKNOWN还是UNKNOWN - 安全替代方案：用
NOT EXISTS（支持 NULL 安全比较）或手动排除NULL：order_status NOT IN ('shipped', 'cancelled') AND order_status IS NOT NULL - MySQL 8.0+、PostgreSQL 支持
NOT IN ... IS NOT NULL语法糖，但兼容性差，别依赖
嵌套 NOT 容易写反逻辑，优先用正向表达
多层 NOT 套 AND/OR 极易出错。比如想排除“状态是 shipped 且金额大于 100”，有人会写：NOT (status = 'shipped' AND amount > 100)。这本身没错，但一旦加需求变成“还要排除 cancelled”，就容易错写成：NOT (status = 'shipped' AND amount > 100) AND NOT status = 'cancelled' —— 实际意图可能是“既不是 shipped+高金额，也不是 cancelled”，但逻辑已变形。
- 德·摩根定律转换后更可靠：
NOT (A AND B)→NOT A OR NOT B；NOT (A OR B)→NOT A AND NOT B - 更推荐重构为正向条件 +
IN或CASE：比如先定义要保留的状态白名单，再取反，比层层NOT更易维护 - 涉及多个字段组合排除时，用
NOT EXISTS关联子查询通常比堆砌NOT更清晰、性能也更好
索引对 NOT 条件基本无效，得换思路
大多数数据库引擎对 NOT column = value 或 NOT IN 几乎不走索引，执行计划常是全表扫描——尤其当排除比例较小时，代价极高。
- 原因：B-tree 索引适合等值或范围查找，
NOT没法利用有序结构快速定位“非某值”的块 - 优化方向：把
NOT转成正向筛选。例如查“非北京用户”，如果北京用户只占 5%，不如先查出北京用户 ID 列表，再用NOT EXISTS或LEFT JOIN ... WHERE id IS NULL - 部分场景可用函数索引兜底，如 PostgreSQL 上建
CREATE INDEX idx_not_vip ON users ((user_level != 'VIP'))，但通用性差，且需确保查询条件完全匹配该表达式
真正麻烦的不是语法怎么写，而是得时刻问自己：这个 NOT 对应的业务含义，是否真的需要“排除”，还是其实该用“明确包含”来表达？后者往往更稳、更快、更少歧义。
