not必须配合布尔表达式使用，不能单独作用于字段；常见错误包括not后接字段名、not in遇null返回unknown、多条件未加括号致逻辑错误；安全替代not in宜用not exists或显式处理null。
NOT 运算符的基本用法和常见错误
SQL 中的 NOT 本身不能单独使用，必须搭配其他逻辑表达式（如 IN、LIKE、BETWEEN、IS NULL 或括号内的完整条件）才能生效。直接写 WHERE NOT name = 'Alice' 虽然语法合法，但容易因空值（NULL）导致意外结果——因为 name = 'Alice' 在 name 为 NULL 时返回 UNKNOWN，而 NOT UNKNOWN 仍是 UNKNOWN，该行不会被选中，但你可能误以为“排除了所有非 Alice 的记录”，其实 NULL 行也被过滤掉了。
- 推荐始终用
IS NOT NULL显式处理空值，而不是依赖NOT = -
NOT IN遇到子查询含NULL会整个返回空结果集——这是高频翻车点 - 嵌套条件必须加括号：
NOT (status = 'active' AND score > 80)，不加括号会变成(NOT status = 'active') AND score > 80，语义完全不同
NOT IN 和 NOT EXISTS 的实际选择
想排除一批 ID，比如“查出所有不在黑名单里的用户”，NOT IN 看似简洁，但只要黑名单表里有任意一个 user_id 是 NULL，整条查询就查不到任何数据。这时候必须换用 NOT EXISTS。
示例：排除 blacklist 表中出现过的 user_id
一款AI数据处理工具，主要用于用于查询 Massive 市场数据端点的 Bash CLI 封装和 OpenClaw 技能，适用于 Codex 或 OpenClaw 代理从 shell 调用，适合需要提升相关任务效率的用户。
SELECT id, name FROM users u WHERE NOT EXISTS ( SELECT 1 FROM blacklist b WHERE b.user_id = u.id );
-
NOT EXISTS对NULL安全，且通常比NOT IN性能更好（尤其大数据量时，可利用索引） -
NOT IN要求子查询列不允许为NULL，否则需提前过滤：NOT IN (SELECT user_id FROM blacklist WHERE user_id IS NOT NULL) - 如果黑名单数据量极小（NOT IN 可读性更高；否则优先选
NOT EXISTS
与 LIKE、BETWEEN 等配合时的边界注意
NOT LIKE 很常用，但通配符位置影响结果。比如 NOT LIKE '%admin%' 会排除含 “admin” 的所有字符串，但 NOT LIKE 'admin%' 只排除以 “admin” 开头的——别漏掉百分号。
-
NOT BETWEEN 10 AND 20等价于20，不是= 21（虽然结果一样，但语义上BETWEEN是闭区间） -
NOT无法直接作用于聚合函数或列别名，比如WHERE NOT total > 100合法，但WHERE NOT sum(amount) > 100必须写成HAVING NOT SUM(amount) > 100（且需配合GROUP BY） - 某些数据库（如 PostgreSQL）支持
NOT ILIKE实现大小写不敏感的否定匹配，MySQL 则要用LOWER(col) NOT LIKE LOWER('%value%')
在 WHERE 和 HAVING 中使用 NOT 的区别
WHERE 中的 NOT 过滤原始行，HAVING 中的 NOT 过滤分组后的结果。混淆两者会导致逻辑错误。例如：想查“平均分不高于 75 的班级”，必须用 HAVING NOT AVG(score) > 75，而不是在 WHERE 里写——因为 AVG() 是聚合函数，WHERE 阶段还不可用。
-
WHERE NOT deleted = 1→ 过滤未删除的原始记录 -
HAVING NOT COUNT(*) > 5→ 分组后只保留成员数 ≤5 的组 - 如果同时需要行级过滤和组级过滤，
WHERE必须写在HAVING前，且不能把本该在WHERE的条件挪到HAVING（性能损失大）
最常被忽略的是空值对 NOT 行为的静默干扰，尤其是 NOT IN 和 NOT = 场景。上线前务必用含 NULL 的测试数据验证逻辑是否符合预期。
