SQL中AND优先级高于OR，混用不加括号会导致逻辑错误；NULL参与布尔运算结果为UNKNOWN而被过滤；视图中避免CASE WHEN、多用IN/EXISTS、显式处理NULL可保性能与正确性。
WHERE里混用AND和OR不加括号，结果就错了
SQL中AND优先级永远高于OR，写成WHERE status = 'draft' OR type = 'report' AND created_at > '2024-01-01'，实际等价于WHERE status = 'draft' OR (type = 'report' AND created_at > '2024-01-01')，而不是你直觉里的“草稿或报表且时间新”。这种隐式分组极易漏数据或查出脏行。
实操建议：
- 只要出现
AND和OR共存，所有逻辑单元必须用括号包裹，例如：WHERE (status = 'draft') OR (type = 'report' AND created_at > '2024-01-01') - 把语义一致的条件先归组，比如状态类：
(status = 'active' OR status = 'pending')，再跟其它组组合 - 用缩进对齐括号层级，肉眼就能看出嵌套是否匹配
NULL值会让整个AND/OR表达式变成UNKNOWN被过滤掉
WHERE rating > 4 AND review_count > 0看着没问题，但只要某行review_count是NULL，整条表达式就是TRUE AND UNKNOWN → UNKNOWN，而WHERE只认TRUE，这行直接消失——不是没数据，是被静默丢弃了。
实操建议：
- 可空字段参与判断时，必须显式处理
NULL：review_count > 0 OR review_count IS NULL，或者用COALESCE(review_count, 0) > 0 - 别写
column = NULL，它永远不成立；要用column IS NULL - 如果业务上
NULL代表“未评分”，那rating IS NULL OR rating > 4可能才是真实意图
视图定义里用CASE WHEN做布尔分支，执行计划容易退化
有人在视图CREATE VIEW v_orders AS SELECT * FROM orders WHERE CASE WHEN :mode = 'active' THEN end_date IS NULL ELSE end_date IS NOT NULL END——语法能过，但多数数据库（PostgreSQL、MySQL、SQL Server）会因此放弃索引下推，全表扫描变常态，且后续加ORDER BY或JOIN时优化器更难决策。
实操建议：
- 视图的
WHERE部分只放纯布尔逻辑，用AND/OR拼接，例如：WHERE (:mode = 'active' AND end_date IS NULL) OR (:mode = 'done' AND end_date IS NOT NULL) - 参数为空时整段失效？加前置守卫：
WHERE COALESCE(:mode, '') IN ('active', 'done') AND ((...)) - 真需要多层嵌套判断（比如VIP+近7天退款），把计算下沉到子查询生成标志列，视图外层只做
WHERE label = 'high_risk'
IN比长串OR更安全，也更容易走索引
写成WHERE type = 'A' OR type = 'B' OR type = 'C' OR type = 'D' OR type = 'E'不仅难维护，MySQL在OR超过5个时可能直接放弃使用type上的索引；PostgreSQL虽支持，但执行计划常不如IN稳定。
实操建议：
- 三个及以上等值判断，一律改用
IN：WHERE type IN ('A', 'B', 'C', 'D', 'E') -
IN列表为空时（IN ()）会报错，动态SQL需提前判空；静态视图可加兜底：WHERE type IN ('A', 'B', 'C') OR 1=0（不推荐，仅作说明） - 若右侧是子查询，优先用
EXISTS而非IN，尤其当子查询字段可能为NULL时，IN行为不可靠
视图里的布尔逻辑不是写得越“像代码”越好，而是越贴近数据库优化器的预期越稳。括号、NULL、IN/EXISTS这些点，表面是语法细节，实际卡着性能和正确性两条命脉。
