不加括号的多条件where查询必然按and优先于or执行，易导致逻辑错误；必须依业务语义显式加括号分组，并对null值用is null/is not null显式处理。
不加括号的多条件 WHERE 查询，大概率逻辑错误——不是“可能出错”，是“必然按 AND 优先规则执行”，而这个规则和你脑中的业务逻辑几乎总不一致。
WHERE 中 AND 和 OR 的默认优先级会悄悄改写你的意图
MySQL、PostgreSQL、SQL Server 等主流数据库中，AND 总是先于 OR 计算，不管书写顺序如何。比如这句：
WHERE status = 'active' OR type = 'A' AND created_at > '2024-01-01'
它实际等价于：
WHERE status = 'active' OR (type = 'A' AND created_at > '2024-01-01')
但你要的很可能是「活跃用户，或者 A 类用户，或者新创建的用户」——也就是三个条件并列满足其一。这时不加括号，created_at 条件就只约束了 type = 'A' 这一分支，漏掉大量本该命中的记录。
- 别靠记忆“AND 优先”来写逻辑，人脑不擅长在嵌套中模拟运算符优先级
- 只要出现
OR，且它和AND在同一层级（即没被外层括号隔离），就必须手动加括号 -
NOT虽然优先级最高，但单独用时不易出错；一旦混入AND/OR，也得括起来，例如NOT (status = 'draft')
按业务语义分组，而不是按运算符类型加括号
括号的作用不是“让代码好看”，是把一组有共同业务含义的条件锁死成一个原子单元。比如“付费用户”包含两个必要条件：is_paid = 1 且 pay_time IS NOT NULL。它们必须一起成立，才构成一个完整语义块。
错误写法（语义松散，后续难维护）：
WHERE is_paid = 1 AND pay_time IS NOT NULL OR user_level = 'vip'
正确写法（显式表达“付费用户”是一个整体）：
WHERE (is_paid = 1 AND pay_time IS NOT NULL) OR user_level = 'vip'
- 每个括号对对应一个可命名的业务概念，如
(is_vip = 1 AND last_login > '2025-01-01')可叫“活跃 VIP” - 避免跨行写半个括号，MySQL 不强制格式，但你在编辑器里每对
()单独成行 + 缩进，能一眼识别嵌套层级 - 即使只有一个
OR，也建议给左右两边都加括号，例如(type = 'A') OR (type = 'B')，方便以后插入新分支
IN 和 OR 混用时，括号位置决定过滤范围
IN 自带括号，但它只是值列表容器，不改变外层逻辑分组。下面这句很危险：
WHERE status IN ('a', 'b') OR type = 'x' AND deleted = 0
由于 AND 优先，它等价于：
WHERE (status IN ('a', 'b')) OR (type = 'x' AND deleted = 0)
但你要的可能是「status 是 a/b，或者 type=x，或者 deleted=0」——那就要写成：
WHERE (status IN ('a', 'b')) OR (type = 'x') OR (deleted = 0)
-
IN本身不解决逻辑分组问题，它只是语法糖，等价于多个=用OR连接 - 当
IN和AND共存于同一OR分支中，务必确认AND是否真的只应约束那个分支，还是该提升为全局条件 - 遇到
IN+AND+OR三层混合，先画出业务真值表，再反推括号结构
NULL 值会让所有比较运算返回 UNKNOWN，必须显式处理
任何字段与 NULL 做 =、!=、> 等比较，结果都不是 TRUE 或 FALSE，而是 UNKNOWN，而 WHERE 只保留 TRUE 行。这意味着：
WHERE col = 'x' OR col != 'y'
如果 col 是 NULL，整行被过滤掉——即使你本意是“取所有非 y 的记录，包括 NULL”。
- 涉及可能为
NULL的字段，必须用IS NULL或IS NOT NULL显式判断 - 想把
NULL当作一个合法值参与逻辑，常用写法：(col = 'x' OR col IS NULL) - 在
CASE或函数中处理NULL时也一样，COALESCE(col, 'default')比直接比较更安全
括号解决的是逻辑结构问题，但 NULL 处理是语义完整性问题——两者缺一不可。哪怕括号全对，漏掉 IS NULL，查询结果照样少数据。
