NOT运算符在WHERE中需用括号包裹多条件再取反，否则逻辑错误；NOT IN遇NULL失效，应改用NOT EXISTS；复杂排他逻辑优先用CASE生成标记列或NOT EXISTS避免歧义。
NOT运算符在WHERE子句中如何正确排除多个条件
直接用 NOT 套多个条件时，最容易掉进逻辑陷阱——它不等价于“全部不满足”，而是对整个布尔表达式取反。比如想排除「状态为 draft 且作者是 admin」的记录，写成 NOT (status = 'draft' AND author = 'admin') 才对；若漏括号写成 NOT status = 'draft' AND author = 'admin'，实际执行的是 (NOT status = 'draft') AND author = 'admin'，语义完全跑偏。
常见错误现象：WHERE NOT status = 'draft' OR NOT author = 'admin' 看似“排除两者”，实则只要 status 不是 draft 或 author 不是 admin 就会命中，几乎把全表筛进来。
- 多条件排他必须用括号包裹原始条件组合，再整体加
NOT - 优先考虑用
NOT IN或NOT EXISTS替代长串NOT (A AND B) OR (C AND D)，可读性与维护性更好 - 注意 NULL：
NOT (col = 'x')对col IS NULL的行返回 UNKNOWN，不会被 WHERE 选中——这常被误认为“没排除成功”，其实是三值逻辑生效
用NOT IN排除一组离散值时的NULL陷阱
NOT IN 表面简洁，但只要右侧列表（或子查询结果）里含任意一个 NULL，整条语句就查不到任何数据。因为 'a' NOT IN ('b', NULL) 等价于 'a' != 'b' AND 'a' != NULL，而 'a' != NULL 永远为 UNKNOWN，导致整个条件不成立。
使用场景：批量剔除已知 ID 列表、禁用用户名、黑名单邮箱域等。
- 子查询务必加
WHERE col IS NOT NULL过滤 NULL，例如：id NOT IN (SELECT id FROM blacklist WHERE id IS NOT NULL) - 确定要排除的值无 NULL 时，用
NOT IN ('a','b','c')没问题；否则改用NOT EXISTS更稳妥 - 性能上，
NOT IN在大表 + 无索引列时可能比LEFT JOIN ... IS NULL慢，尤其 MySQL 5.7 及以前版本
NOT EXISTS替代NOT IN规避NULL和性能问题
NOT EXISTS 是最接近自然语言“不存在对应记录”意图的写法，既绕过 NOT IN 的 NULL 缺陷，又通常能利用关联字段索引加速。
示例：查所有没下过订单的用户
SELECT u.id, u.name FROM users u WHERE NOT EXISTS ( SELECT 1 FROM orders o WHERE o.user_id = u.id );
- 子查询中
SELECT 1是惯用写法，不关心具体字段，只判断是否存在 - 必须写关联条件（如
o.user_id = u.id），否则变成无关联子查询，可能产生笛卡尔积 - 如果子查询里有
WHERE条件含 NULL 值（如o.status = NULL），记得改成o.status IS NULL，否则永远不匹配
复杂排他逻辑该用CASE WHEN还是WHERE过滤
当排他规则带优先级或依赖上下文（比如“非VIP用户排除价格>100的，VIP用户排除价格>500的”），硬塞进 NOT 表达式会让 WHERE 变得难读难调。此时应拆解：先用 CASE WHEN 计算出是否“应被排除”的标记列，再统一过滤。
- WHERE 里嵌套多层
CASE易出错，优先在子查询或 CTE 中生成should_exclude布尔列 - 数据库对
CASE的索引支持有限，高频查询建议把排他规则固化到物化视图或预计算字段 - 某些场景（如动态权限过滤）用
NOT EXISTS配合参数化子查询更灵活，避免 CASE 分支爆炸
多重排他真正的复杂点不在语法，而在业务规则本身是否自洽——比如“排除A且排除B”和“排除A或B”经常被产品需求文档混用，写SQL前最好用真值表手算几组样例验证逻辑。
