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，性能常差十倍。
