SQL复杂查询需逻辑分层、括号明确优先级、高选择性条件前置、避免字段函数操作、合理使用CASE WHEN，并通过EXPLAIN验证执行计划。
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） - 正确写法：
WHERE status = 'active' AND (type = 'user' OR type = 'admin')，意图清晰，结果可控 - 建议：只要出现 OR，就给它所在的逻辑组加上括号；多层嵌套时，缩进+换行提升可读性
把可下推的过滤条件尽量往前放
数据库优化器通常按 FROM → WHERE → GROUP BY → HAVING → ORDER BY → LIMIT 的顺序执行。WHERE 中越早排除无效行，后续计算越轻量。
- 优先放高选择性条件（如主键=、唯一索引字段=、时间范围窄）
- 避免在 WHERE 中对字段做函数操作：
WHERE YEAR(create_time) = 2024会导致索引失效；改用WHERE create_time >= '2024-01-01' AND create_time - 字符串模糊匹配慎用前导通配符：
LIKE '%abc'无法走索引；能用LIKE 'abc%'就不用全模糊
IN 和 EXISTS 别乱换，场景决定效率
两者语义不同，性能表现也依赖数据量和索引情况，不能一概而论“哪个更快”。
- 子查询结果集小（几十到几百行）、外表大 → 用
IN更直观，多数引擎能优化为哈希查找 - 子查询结果集大、外表小，或需关联多字段 → 用
EXISTS更稳，可提前终止（找到即停），且支持相关子查询 - 注意 NULL：
IN (NULL, ...)整个条件返回 UNKNOWN，常被忽略导致漏数据；EXISTS不受 NULL 影响
用 CASE WHEN 统一复杂判断，少写重复子查询
多个条件需要分类统计或生成衍生字段时，避免反复写相似子查询或 JOIN，用 CASE WHEN + 聚合更简洁高效。
- 例如统计各状态用户数：
COUNT(CASE WHEN status = 'active' THEN 1 END) AS active_cnt，比多次 COUNT+WHERE 更快 - 生成分级标签：
CASE WHEN score >= 90 THEN 'A' WHEN score >= 80 THEN 'B' ELSE 'C' END AS level - 注意：CASE WHEN 在 WHERE 中可用，但部分数据库不支持在 ON 条件中使用复杂 CASE，需实测
基本上就这些。复杂查询不是炫技，而是让条件之间有层次、有分工、有依据。写完多看一眼执行计划（EXPLAIN），比背一百条技巧都管用。
