SQL复杂查询需分层组织条件、用括号明确逻辑优先级、合理使用JOIN与子查询；先厘清业务需求与表关系，再分基础/关联/计算三层过滤，最后通过CTE拆解可读性差的场景。
SQL复杂条件查询不是堆砌WHERE子句，而是围绕业务逻辑分层组织条件、合理使用括号控制优先级、结合JOIN与子查询拆解多维约束。核心在于“先想清楚要什么，再决定怎么写”，而不是一上来就拼AND/OR。
明确查询目标与数据关系
动手写SQL前，先用自然语言描述需求。比如：“查2024年销售额超5万、且来自华东区、且客户等级为VIP的订单，需包含客户名、订单号、商品类别和实付金额”。这一步能帮你识别出：时间范围（2024年）、数值阈值（5万）、地域维度（华东区）、标签维度（VIP）、关联实体（客户、订单、商品）。
接着画出表间关系：订单表（orders）关联客户表（customers）和商品表（products），客户表含区域和等级字段，订单表含日期和金额字段。关系理清了，JOIN路径和过滤位置就明确了。
分层组装WHERE条件：基础过滤 → 关联过滤 → 计算过滤
把条件按执行效率和语义层级分三类处理：
-
基础过滤：直接作用于主表的高选择性条件，如
order_date BETWEEN '2024-01-01' AND '2024-12-31'或status = 'completed'，放在WHERE最前面，利于索引下推 -
关联过滤：来自JOIN表的条件，如
c.region = '华东'或c.level = 'VIP'，写在ON子句（推荐）或WHERE中；若写在ON里，能影响JOIN结果集大小；写在WHERE里，则是JOIN后再过滤 -
计算过滤：涉及聚合或表达式的结果筛选，如
SUM(o.amount) > 50000，必须配合GROUP BY，并用HAVING而非WHERE
用括号显式定义逻辑优先级，避免隐式歧义
AND优先级高于OR，但人脑容易误读。例如：type = 'A' OR type = 'B' AND status = 'active' 实际等价于 type = 'A' OR (type = 'B' AND status = 'active')，而非你想表达的“（A或B）且active”。
正确写法一律加括号：
- 多条件“或”组合统一包一层：
(type = 'A' OR type = 'B') - 混合逻辑时先分组再连接：
((region = '华东' OR region = '华南') AND level = 'VIP') OR (is_partner = 1) - IN与NOT IN搭配NULL安全判断：
(category IN ('电子', '家电') OR category IS NULL)，避免NULL导致整行被过滤
复杂场景用子查询或CTE分步实现
当单条SQL嵌套过深、可读性下降时，优先用CTE（WITH子句）拆解步骤。例如统计“每个VIP客户的年度复购次数+首单金额”：
WITH vip_orders AS (
SELECT o.order_id, o.customer_id, o.amount, o.order_date
FROM orders o
JOIN customers c ON o.customer_id = c.id
WHERE c.level = 'VIP'
AND o.order_date >= '2024-01-01'
),
first_order AS (
SELECT customer_id, MIN(order_date) as first_date
FROM vip_orders
GROUP BY customer_id
),
first_amount AS (
SELECT vo.customer_id, vo.amount as first_amount
FROM vip_orders vo
JOIN first_order fo ON vo.customer_id = fo.customer_id AND vo.order_date = fo.first_date
)
SELECT
vo.customer_id,
COUNT(*) AS reorder_count,
fa.first_amount
FROM vip_orders vo
JOIN first_amount fa ON vo.customer_id = fa.customer_id
GROUP BY vo.customer_id, fa.first_amount;
每段CTE只做一件事：筛选人群 → 找首单时间 → 取首单金额 → 最终聚合。调试时可单独运行任一CTE验证中间结果。
基本上就这些。复杂查询不是靠技巧堆出来的，而是靠把业务问题拆解成可执行的数据动作。写完多问一句：这个条件放这里，会不会漏掉该查的数据？会不会多查了不该查的？答案清晰了，SQL就稳了。
