SQL 复杂条件查询的核心是逻辑分组、优先级控制与数据关系理解；需用括号明确 AND/OR 优先级，合理选用 IN/BETWEEN/LIKE，清晰划分 JOIN ON 与 WHERE 职责，并用 CASE WHEN 简化多分支逻辑。
SQL 复杂条件查询不是堆砌 WHERE 子句，而是围绕 逻辑分组、优先级控制、数据关系理解 三层核心展开。关键不在写得多，而在分得清、括得准、联得对。
一、括号是逻辑的“标点符号”，不是可选项
AND 和 OR 默认优先级不同（AND 优先于 OR），不加括号极易误读。比如：
错误写法：WHERE status = ‘active’ AND type = ‘user’ OR type = ‘admin’
这实际等价于：(status = ‘active’ AND type = ‘user’) OR type = ‘admin’——所有 admin 都会被查出，哪怕 status 是 ‘inactive’。
正确写法：WHERE status = ‘active’ AND (type = ‘user’ OR type = ‘admin’)
明确表达：只要 status 是 active，且 type 属于 user 或 admin 任一即可。
- 每组逻辑含义独立时，必须用小括号包裹
- 嵌套条件（如多层 OR+AND 混合）建议逐层加括号，哪怕看起来冗余
- 用格式化 工具 或手动缩进让括号结构一目了然，避免“括号迷宫”
二、IN、BETWEEN、LIKE 不是万能替代，要懂适用边界
初学者常滥用 IN 替代多个 OR，但要注意：
- IN 适合离散、数量适中（一般 ≤ 数百）、确定值的匹配；值太多会拖慢性能，甚至触发数据库限制
- BETWEEN 仅适用于连续闭区间，且左右值类型必须严格一致（如日期、数字），不能用于模糊文本范围
- LIKE 带前导通配符（’%abc’）无法走索引；想高效查前缀，用 ‘abc%’ 才可能命中索引
- 需要排除 NULL？IN 不包含 NULL，要用 IS NULL 单独判断
三、JOIN + WHERE 的分工必须清晰
多表关联时，条件放 JOIN ON 还是 WHERE，直接影响结果集和性能：
- ON 条件：定义两表如何关联，决定连接结果的“形状”。外连接（LEFT/RIGHT JOIN）中，ON 中的过滤只影响右 / 左表匹配行为
- WHERE 条件：对最终连接结果做全局筛选。若在外连接后加 WHERE 过滤左表字段为 NULL，可能把本该保留的左表记录也剔除，变相转成内连接
- 原则：关联逻辑放 ON，业务筛选放 WHERE；不确定时，先写 ON 关联，再在 WHERE 加业务约束，最后用 EXPLAIN 看执行计划是否合理
四、用 CASE WHEN 把“多条件分支”变成单字段决策
当查询需按复杂规则分类统计（如按订单金额分档、按时间动态计算状态），硬写多重嵌套 AND/OR 易错难维护。此时用 CASE WHEN 更直观可靠：
例如：标记用户活跃等级
SELECT user_id, CASE WHEN last_login >= CURRENT_DATE - INTERVAL '7 days' THEN '活跃' WHEN last_login >= CURRENT_DATE - INTERVAL '30 days' THEN '沉默' ELSE '流失' END AS activity_level FROM users;- CASE 表达式可在 SELECT、WHERE、ORDER BY、GROUP BY 中使用，统一逻辑出口
- 避免在 WHERE 中写大量 OR 分支判断，改用 CASE 配合别名 + HAVING（聚合后）或子查询
- 注意 ELSE 必须存在（或明确写 ELSE NULL），防止意外 NULL 干扰分组或排序
基本上就这些。复杂条件不是靠记忆语法，而是养成“先画逻辑图、再定括号层、最后选操作符”的习惯。练多了，一眼就能看出哪段该包、哪条该挪、哪个 NULL 被悄悄忽略了。
