括号是强制要求——where中同时出现and和or时必须加括号，否则因and优先于or导致逻辑错误；in替代多or更安全高效；not需括号包裹复合条件；null参与and时须显式处理。
括号不是可选，是强制要求——只要WHERE里同时出现AND和OR，不加括号的结果几乎肯定和你想要的不一致。
为什么WHERE a = 1 OR b = 2 AND c = 3查出意外数据？
因为AND永远先于OR执行，这行语句实际等价于WHERE a = 1 OR (b = 2 AND c = 3)，而不是你脑中默认的WHERE (a = 1 OR b = 2) AND c = 3。这种“直觉 vs 解析器”的错位，是线上查询逻辑错误最常见源头之一。
实操建议：
- 所有含
AND和OR的组合，一律手动加括号，哪怕只有一处OR - 先在纸上写清业务逻辑：比如“（北京或上海）且女性”，再转成
(city = '北京' OR city = '上海') AND gender = '女' - 别依赖缩进或换行——SQL引擎完全不认格式，只认括号
- MySQL、PostgreSQL、SQL Server 全部遵循该优先级，换库不会自动修复
IN比一长串OR更安全、更高效
写WHERE status = 'active' OR status = 'pending' OR status = 'shipped'不仅难读，还容易漏掉一个OR导致语法错误；更重要的是，某些数据库优化器面对大量OR时会放弃走索引，尤其当字段没建索引或类型隐式转换时。
实操建议：
- 三个及以上等值判断，直接改用
IN：WHERE status IN ('active', 'pending', 'shipped') -
IN列表别超几百项：SQLite有编译限制，MySQL受max_allowed_packet约束；超量时拆查询或用临时表 -
IN对NULL免疫：WHERE id IN (1, 2, NULL)中NULL部分被静默忽略，需单独补OR id IS NULL
NOT只否定紧邻表达式，多条件否定必须套括号
NOT status = 'deleted' OR status = 'archived'实际是(NOT status = 'deleted') OR status = 'archived'，意思是“非deleted 或者是archived”，和你想表达的“既不是deleted也不是archived”完全相反。
实操建议：
-
NOT后面只要接了含AND/OR的复合条件，就必须用括号包住整个子表达式 - 否定“任一成立”：写
NOT (a = 1 OR b = 2)；否定“全部成立”：写NOT (a = 1 AND b = 2) - 能用
!=或代替NOT column = value的地方就直写，但注意!= NULL永远不成立，仍需IS NOT NULL - PostgreSQL中
NOT IN (1, 2, NULL)整条返回空结果——这不是bug，是标准行为，务必提前过滤NULL
高区分度条件前置 + NULL显式处理
WHERE条件顺序不影响最终结果，但影响可读性和维护性。更重要的是，涉及可空字段的AND极易意外丢数据：比如WHERE rating > 4 AND review_count > 0，只要某行review_count为NULL，整条布尔表达式就变成TRUE AND UNKNOWN → UNKNOWN，该行直接被过滤——而你可能根本没意识到字段允许为空。
实操建议：
- 把高区分度、带索引的条件放前面，比如主键等值、时间范围，方便后续接手的人一眼抓住筛选主干
- 所有可能为
NULL的字段参与AND时，必须显式声明意图：review_count > 0 OR review_count IS NULL，或用COALESCE(review_count, 0) > 0 - 避免
OR连接带函数的条件，如UPPER(name) = 'MARY' OR age + 1 > 30——基本无法走索引，大表上性能断崖式下跌
真正卡住人的从来不是语法会不会写，而是“这个括号到底该包住哪几个条件”——业务逻辑越复杂，越要先画逻辑树，再落笔写SQL。
