sql中and优先级高于or，混用时必须加括号明确逻辑；多值匹配应使用in而非冗长or；not作用范围仅限紧邻表达式，否定多条件需括号包裹；动态条件宜服务端拼接而非sql内case判断。
WHERE里混用AND和OR不加括号，结果完全不对
SQL里AND优先级高于OR，这点和大多数编程语言一致，但写查询时很容易下意识忽略。比如想查“北京的男用户”或“上海的女用户”，写成 WHERE city = '北京' AND gender = '男' OR city = '上海' AND gender = '女' 看似合理，实际等价于 (city = '北京' AND gender = '男') OR (city = '上海' AND gender = '女') —— 这个没问题；但要是写成 WHERE city = '北京' OR city = '上海' AND gender = '女'，就变成“北京任意性别 + 上海女性”，不是你想要的“北京女性或上海女性”。
实操建议：
- 所有含
AND和OR的组合，一律用括号明确分组，哪怕你觉得“这里肯定不会错” - 把逻辑先写在纸上：(A AND B) OR (C AND D)，再照搬进SQL，别边想边敲
- MySQL/PostgreSQL/SQL Server都遵循这个优先级，别指望换数据库就“自动修好”
IN配合OR写一堆=条件，又慢又难维护
想查多个城市，有人这么写：WHERE city = '北京' OR city = '上海' OR city = '广州' OR city = '深圳'。可读性差，执行计划也容易走不了索引（尤其字段没建索引时），还容易漏掉一个OR导致语法错误。
实操建议：
- 用
IN替代一长串OR：WHERE city IN ('北京', '上海', '广州', '深圳') -
IN里的值别超过几百个——SQLite有编译限制，MySQL默认max_allowed_packet也可能截断；超量时拆成多个查询或用临时表 - 注意
NULL在IN里永远不匹配：WHERE status IN ('active', NULL)中NULL部分无效，得单独写OR status IS NULL
NOT与AND/OR连用时语义容易翻车
NOT作用范围只覆盖紧挨着的表达式，不是整条WHERE。比如WHERE NOT status = 'deleted' AND created_at > '2023-01-01'，实际是(NOT status = 'deleted') AND created_at > '2023-01-01'，没问题；但WHERE NOT (status = 'deleted' OR status = 'archived')才是“既不是deleted也不是archived”。少一对括号，意思就反了。
实操建议：
- 否定多条件时，一定把整个条件组用括号包住，再加
NOT - 能用
!=或代替NOT =的地方就别绕弯，更直白（但注意NULL比较仍需IS NOT NULL） - PostgreSQL支持
NOT IN，但只要列表里有NULL，整条NOT IN返回空结果——这是陷阱，不是bug
参数化查询里传入动态条件，拼SQL还是用CASE？
后端拼接SQL时，如果某些条件可能为空（比如搜索框没填城市），直接拼AND city = ?会导致语法错误。有人用CASE WHEN硬塞进WHERE，结果执行计划变复杂、索引失效。
实操建议：
- 服务端拼SQL时，用逻辑判断控制是否追加
AND city = ?子句，而不是让SQL自己判断 - 避免在WHERE里用
CASE做条件开关，例如AND (CASE WHEN ? IS NOT NULL THEN city = ? ELSE 1=1 END)——这会让优化器放弃索引 - ORM如MyBatis的
<if></if>、Django ORM的Q对象，本质也是动态拼条件，原理一样：生成干净的SQL，而不是塞一堆兜底逻辑
括号不是装饰，是逻辑的锚点；参数化不是防注入的终点，而是动态条件的起点。写完WHERE，先看一眼括号配对没，再想想NULL怎么处理——这两步跳过，后面调半天执行计划都救不回来。
