SQL中WHERE多条件混用需警惕逻辑优先级、NULL行为、函数索引失效和动态参数陷阱；务必用括号明确OR组、避免字段函数调用、区分NULL与空值处理，并优先业务层动态拼接条件。
WHERE子句里多个AND/OR混用时逻辑容易错乱
SQL里写一堆 AND 和 OR 不是简单堆砌，括号缺失会直接改变执行顺序。比如 WHERE status = 'active' OR type = 'vip' AND created_at > '2024-01-01' 实际等价于 WHERE status = 'active' OR (type = 'vip' AND created_at > '2024-01-01')，而不是你脑内想的“所有条件都得满足”。
实操建议：
- 所有
OR组合必须用括号显式包裹，例如：WHERE (status = 'active' OR status = 'pending') AND type IN ('vip', 'trial') - 把语义上属于同一组的条件先归并，再外层组合，避免嵌套过深
- 用换行+缩进对齐括号层级，肉眼可读性比省字符重要得多
IN、BETWEEN、LIKE 和 NULL 判断在多条件中行为不一致
IN 和 BETWEEN 看似方便，但遇到 NULL 会静默失效；LIKE 的通配符位置影响索引是否生效；而 IS NULL 不能写成 = NULL——这些在多条件拼接时特别容易漏掉。
实操建议：
-
IN列表里别混NULL，它不会被匹配到，要单独加OR column IS NULL -
LIKE开头用%（如LIKE '%abc'）基本走不了索引，高频查询考虑全文索引或前缀字段 - 日期范围优先用
BETWEEN，但注意它是闭区间，BETWEEN '2024-01-01' AND '2024-01-31'包含 1 月 31 日 00:00:00，不含 23:59:59
WHERE 中函数调用导致索引失效
在字段上套函数（比如 UPPER(name)、DATE(created_at)、COALESCE(status, 'draft')）会让绝大多数数据库放弃使用索引，尤其在大表上，性能断崖式下跌。
实操建议：
- 能用字段原值比较就别加工，比如查大小写不敏感的用户名，建函数索引或用
ILIKE（PostgreSQL）/COLLATE utf8mb4_0900_as_cs（MySQL 8.0+） - 时间范围筛选别写
DATE(created_at) = '2024-01-01'，改用created_at >= '2024-01-01' AND created_at - 确认执行计划：MySQL 用
EXPLAIN，PostgreSQL 用EXPLAIN ANALYZE，重点看key或Index Scan是否出现
动态拼接 WHERE 条件时参数为空的处理陷阱
后端拼 SQL（尤其 ORM 原生查询或模板拼接）时，常遇到用户没填某搜索项，结果生成了 WHERE ... AND category = NULL 或 AND price > '' 这种无效甚至报错的条件。
实操建议：
- 空字符串、
0、NULL输入值必须提前过滤，不是丢给 SQL 处理 - 用
COALESCE或NULLIF在 SQL 层兜底（仅限简单场景），例如：AND status = COALESCE(:status, status)，但要注意这会阻止索引下推 - 更稳妥的是业务层控制 SQL 片段生成逻辑，比如 Python 用
if status:动态加条件，而不是全量拼完再删
WHERE 子句里可能同时踩中逻辑优先级、NULL 行为、函数索引、动态参数四个坑——调试时得一个一个隔离验证，不能只看结果对不对。 
