复杂条件查询需分层组织逻辑：先明确业务目标，再分四层过滤（时间、状态、客户有效性、聚合排序）；多表关联时ON精确约束、WHERE最终筛选；优先用EXISTS替代IN；动态条件用布尔表达式而非拼SQL。
复杂条件查询不是堆砌 WHERE 子句，而是围绕业务目标，分层组织逻辑、合理利用连接与子查询、精准控制数据粒度。关键在“先想清楚要什么，再决定怎么拿”。
明确业务意图，再反推SQL结构
比如需求是：“查上月销售额 Top 10 的客户，且只统计已完成订单，排除测试账号和已注销客户”。这不是简单筛选，而是四层过滤：
- 时间范围：订单创建时间 ∈ 上月（用 DATE_TRUNC 或 BETWEEN + 动态计算）
- 状态过滤：order_status = 'completed'（不是 'pending' 或 'cancelled'）
- 客户有效性：customer.status IN ('active', 'trial')，且 customer.email NOT LIKE '%test%'
- 聚合排序：按 SUM(amount) 降序，LIMIT 10
写之前先列这四点，能避免 WHERE 里混入 JOIN 条件或漏掉 NULL 处理。
多表关联不硬连，用 ON 精确约束，WHERE 做最终筛
常见错误是把所有条件都塞进 WHERE，导致 LEFT JOIN 变 INNER JOIN。例如查客户+最近订单+订单商品数：
SELECT c.name, o.order_id, COUNT(i.id) items_cnt FROM customers c LEFT JOIN orders o ON c.id = o.customer_id AND o.status = 'completed' LEFT JOIN order_items i ON o.id = i.order_id WHERE c.created_at >= '2024-01-01'
注意：o.status = 'completed' 放在 ON 而非 WHERE，否则 LEFT JOIN 失效；而时间过滤放 WHERE，因它作用于主表 customers。
嵌套逻辑优先用 EXISTS/NOT EXISTS，少用 IN (子查询)
要查“有至少2笔已完成订单的客户”，别写：
WHERE c.id IN (SELECT customer_id FROM orders GROUP BY customer_id HAVING COUNT(*) >= 2)
更稳写法是：
WHERE EXISTS ( SELECT 1 FROM orders o WHERE o.customer_id = c.id AND o.status = 'completed' GROUP BY o.customer_id HAVING COUNT(*) >= 2 )
原因：EXISTS 不依赖返回值内容，语义清晰；且对 NULL 安全，执行计划通常更优；IN 遇到子查询返回 NULL 时整行被过滤，易出错。
动态条件用 CASE 或布尔表达式，避免拼SQL
报表常需“按参数切换统计口径”，比如：参数 @include_refund=1 时计入退款订单，否则忽略。不用 IF ELSE 拼字符串，改用：
AND ( (@include_refund = 1) OR (o.refund_amount = 0 OR o.refund_amount IS NULL) )
或更清晰的布尔组合：
AND o.status = 'completed' AND (o.refund_amount = 0 OR @include_refund = 1)
这种写法可读性强，执行计划稳定，也方便加索引（如 (status, refund_amount) 联合索引）。
基本上就这些。复杂查询不是炫技，而是把业务规则一层层翻译成数据库能懂的语言——先分清“哪些是连接前提，哪些是结果筛选，哪些是聚合约束”，再选对语法工具。练多了，看需求就能脑内生成执行路径。
