SQL复杂条件查询需分层设计：先主干过滤，再关联约束，最后业务规则；用括号明确逻辑优先级，同类维度分组括起，NOT套括号外；IN/EXISTS/JOIN按场景选用；时间+状态+分组分步叠加；动态阈值用CASE WHEN或配置表。
SQL复杂条件查询不是堆砌WHERE子句，而是理清逻辑关系、控制执行顺序、兼顾可读性与性能。关键在“分层设计”：先定主干过滤，再加关联约束，最后补业务规则。
用括号明确优先级，别依赖默认运算顺序
AND 优先级高于 OR，但人脑容易误判。比如想查“北京的男用户或上海的女用户”，写成 WHERE city='北京' AND gender='男' OR city='上海' AND gender='女' 看似合理，实际可能因优化器或版本差异出错。
- 始终用括号包裹每组完整条件：WHERE (city='北京' AND gender='男') OR (city='上海' AND gender='女')
- 多条件组合时，把同类维度（如地域、状态、时间）各自括起来，再用AND/OR连接
- 遇到NOT，直接套在括号外：NOT (status='已取消' OR status='已过期') 比 status!='已取消' AND status!='已过期' 更安全
IN、EXISTS、JOIN选对场景，别硬套一种写法
查“订单表中存在对应用户且用户等级≥VIP”的数据，三种写法结果可能一致，但效率和语义差别很大：
- IN适合小列表匹配（如 user_id IN (101, 205, 333)），但子查询返回NULL会导致整行丢失，慎用于可能含NULL的字段
- EXISTS强调“是否存在”，适合半连接场景；子查询只判断有无，不取值，通常比IN快，尤其外层大、内层小时
- INNER JOIN适合需要取关联表字段，或要利用索引驱动连接顺序；但若只判断存在性却写了JOIN + SELECT *，属于冗余计算
时间范围+状态+分组条件，分步叠加更可控
查“近30天内已完成、且平均订单金额＞500、且至少有3笔订单的用户”，不要一气呵成写超长WHERE：
- 第一步：限定基础时间范围和主状态——WHERE order_time >= DATE_SUB(NOW(), INTERVAL 30 DAY) AND status = '已完成'
- 第二步：用GROUP BY + HAVING筛聚合结果——GROUP BY user_id HAVING COUNT(*) >= 3 AND AVG(amount) > 500
- 第三步：若还需关联用户信息（如昵称、注册渠道），再LEFT JOIN用户表，避免在WHERE里对关联字段过滤导致意外丢行
用CASE WHEN提前收口，减少嵌套判断
当WHERE里出现“按不同城市执行不同金额阈值”这类动态条件，别写多个OR分支硬拼：
- 错误示范：WHERE (city='北京' AND amount > 800) OR (city='深圳' AND amount > 600) OR (city='成都' AND amount > 400)
- 推荐用CASE WHEN在HAVING或子查询中统一处理：HAVING AVG(CASE city WHEN '北京' THEN amount END) > 800 OR AVG(CASE city WHEN '深圳' THEN amount END) > 600（根据实际需求调整）
- 更灵活的做法是把阈值规则抽成配置表，用LEFT JOIN关联后直接比较：ON t.city = r.city AND t.amount > r.min_amount
基本上就这些。复杂条件不是越长越强，而是每层都清楚“我在筛什么、为什么这么筛”。写完多看两眼执行计划，改一个括号或换一次JOIN，性能常差十倍。
