SQL复杂查询核心是依业务意图分层构建逻辑：先单行筛选（时间、状态、模糊匹配），再分组聚合（HAVING），最后跨表判断（EXISTS/NOT EXISTS），并注意NULL处理与括号优先级。
SQL复杂条件查询的核心是把多个逻辑关系（AND/OR/NOT）、范围判断（BETWEEN、IN、LIKE）、空值处理（IS NULL）和函数计算（DATE、CASE等）合理组合起来，关键不是堆砌条件，而是理清业务意图再映射成SQL逻辑。
多状态+时间范围+关键词模糊匹配
典型场景：查“最近30天内，订单状态为‘已发货’或‘已完成’，且商品标题含‘无线’或‘蓝牙’的订单”。
说明：这里混用了时间筛选、多值枚举、模糊文本三类条件，容易漏掉括号导致逻辑错乱。
- 用 BETWEEN CURRENT_DATE - INTERVAL 30 DAY AND CURRENT_DATE 安全限定时间（比 >= + <= 更简洁不易出错）
- 状态用 status IN ('shipped', 'completed')，别写成 status = 'shipped' OR status = 'completed'
- 关键词用 title LIKE '%无线%' OR title LIKE '%蓝牙%'；如果字段支持全文索引，可考虑 MATCH...AGAINST 提升性能
- AND 和 OR 混用时，务必用括号明确优先级，例如：(status IN (...) AND created_at BETWEEN ...) AND (title LIKE ... OR title LIKE ...)
排除特定组合 + 空值优先处理
典型场景：查“所有用户，但要排除‘VIP等级为空’且‘注册时间早于2020年’的用户；同时把 VIP 等级为 NULL 的用户排在结果最前面”。
说明：既要过滤，又要排序，还涉及 NULL 的特殊语义（它不等于任何值，包括自身）。
- 排除条件写成：NOT (vip_level IS NULL AND register_time < '2020-01-01')，不能写成 vip_level IS NOT NULL OR register_time >= '2020-01-01'（逻辑等价但可读性差）
- 排序时让 NULL 排第一：ORDER BY vip_level IS NULL DESC, vip_level（MySQL 支持布尔表达式排序，TRUE=1，FALSE=0）
- 其他数据库如 PostgreSQL 可用 ORDER BY vip_level NULLS FIRST
动态范围校验 + 条件聚合辅助判断
典型场景：查“近7天每日下单人数超50人、且平均客单价高于300元的日期”。
说明：这不是单行判断，而是先分组聚合，再对聚合结果加条件——必须用 HAVING，不能用 WHERE。
- 先按日期分组：GROUP BY DATE(order_time)
- 统计人数：COUNT(DISTINCT user_id)（去重防同一用户多单干扰）
- 算均价：AVG(amount)
- 过滤聚合结果：HAVING COUNT(DISTINCT user_id) > 50 AND AVG(amount) > 300
- 时间范围仍放 WHERE：WHERE order_time >= CURRENT_DATE - INTERVAL 7 DAY（先过滤再聚合，提升效率）
关联表条件穿透 + 子查询精简主表
典型场景：查“购买过‘手机壳’类商品、且近3个月未下单的用户”。
说明：需跨订单、订单明细、商品表，并区分“买过”和“近期没买”两个相反动作，适合用 EXISTS + NOT EXISTS 组合。
- “买过手机壳”：EXISTS (SELECT 1 FROM orders o JOIN order_items oi ON o.id=oi.order_id JOIN products p ON oi.product_id=p.id WHERE p.category='phone_case' AND o.user_id=u.id)
- “近3个月未下单”：NOT EXISTS (SELECT 1 FROM orders o WHERE o.user_id=u.id AND o.created_at >= CURRENT_DATE - INTERVAL 3 MONTH)
- 主查询只查 users 表，避免 JOIN 导致重复或漏数据；子查询里及时关联 user_id，防止笛卡尔积
基本上就这些。复杂查询不是语法堆叠，而是把一句人话业务需求，拆解成“先筛什么、再怎么算、最后留哪些”的执行链条。写完多问自己一句：这个条件是在单行上生效？还是在分组后生效？还是依赖另一张表？答案清楚了，SQL自然就稳了。
