NOT是逻辑否定操作符，须配合布尔表达式使用；常见错误包括NOT后接字段名、NOT IN遇NULL返回UNKNOWN、NOT LIKE不匹配NULL、括号缺失致优先级错误；安全替代NOT IN宜用NOT EXISTS或LEFT JOIN；NULL判断必须用IS NULL/IS NOT NULL。
NOT 运算符的基本用法和常见错误
SQL 中的 NOT 是一元逻辑运算符，作用是对紧跟其后的布尔表达式取反。它不等于“排除某值”的直觉操作——比如 NOT column = 'A' 看似简单，但遇到 NULL 时会返回 UNKNOWN，而 WHERE 只保留 TRUE 行，导致结果意外丢失。
实际使用中，最常踩的坑是直接套用 NOT (condition) 却没考虑三值逻辑（TRUE/FALSE/UNKNOWN），尤其在字段可能为 NULL 的场景下。
-
NOT column IS NULL安全，等价于column IS NOT NULL -
NOT column = 'X'在column为NULL时不匹配任何行（不是返回NULL行，而是跳过） - 想同时排除
'X'和NULL？得显式写成：column IS NOT NULL AND column != 'X'
NOT 与 IN、BETWEEN、EXISTS 的组合写法
NOT 常和集合类谓词搭配，但语法位置和语义容易混淆。关键是记住：它修饰的是整个括号内的逻辑表达式，不是某个字段或值。
例如，要查“不属于某几个状态”的记录，别写成 status NOT IN ('draft', 'archived') 就完事——如果 status 列含 NULL，整条 NOT IN 表达式会变成 UNKNOWN，该行被过滤掉（哪怕你本意是保留 NULL）。
- 安全写法（显式处理
NULL）：(status NOT IN ('draft', 'archived') OR status IS NULL) -
NOT BETWEEN 10 AND 20等价于value 20，但注意边界包含性一致 -
NOT EXISTS是高效反关联手段，比NOT IN更可靠（不受NULL影响），例如：SELECT * FROM orders o WHERE NOT EXISTS (SELECT 1 FROM returns r WHERE r.order_id = o.id)
NOT 和索引使用的实际影响
多数数据库对 NOT 条件（如 NOT column = 'X' 或 NOT IN）难以有效走索引，尤其是当列选择性不高时，优化器往往放弃索引扫描，改用全表扫描。
这不是语法错误，而是执行计划层面的现实约束。如果你发现加了 NOT 后查询变慢，先看执行计划里是否出现 Seq Scan 或 Index Scan Backward 类型的降级。
- 可尝试重写为正向条件 +
UNION ALL（如拆成多个=改成IN）再取补集 - 对高频
NOT查询，考虑建函数索引（PostgreSQL）或计算列+索引（SQL Server） -
NOT LIKE 'prefix%'几乎无法利用前缀索引，应避免在大表上使用
不同数据库对 NOT 的兼容性细节
标准 SQL 中 NOT 行为一致，但部分方言在简写形式上有差异。例如 MySQL 允许 != 和 ，但 PostgreSQL 不支持 !column 这类 C 风格非运算；SQL Server 的 NOT 可用于 UPDATE ... SET flag = NOT flag，而 SQLite 要写成 flag = CASE WHEN flag THEN 0 ELSE 1 END。
- PostgreSQL 支持
NOT修饰整个子查询，如：WHERE NOT (SELECT true FROM other_table WHERE id = t.id) - MySQL 8.0+ 对
NOT IN的NULL处理更严格，建议统一用NOT EXISTS - Oracle 中
NOT不能直接用于ORDER BY表达式（如ORDER BY NOT active报错），需用CASE
真正麻烦的从来不是写对 NOT，而是它悄悄把 NULL 行吞掉，又不报错——查不到数据时，先盯住执行计划和 IS NULL 检查。
