SQL复杂报表核心是分层拆解：内层清洗数据，中间层单维聚合或关联，外层实现呈现逻辑；优先用CTE提升可读性与复用性，窗口函数替代冗余嵌套，尽早过滤、小表驱动、慎用LEFT JOIN的WHERE条件。
写SQL复杂报表，核心不是堆砌嵌套，而是分层拆解逻辑：先理清业务需求要什么数据、哪些维度要聚合、哪些条件需过滤或关联，再一层层用子查询、CTE或窗口函数把计算步骤“具象化”。嵌套本身只是手段，清晰表达计算意图才是关键。
明确每层子查询的职责：别让一层干多件事
多层嵌套容易变成“一锅炖”——FROM里套SELECT，SELECT里又套SELECT，结果难读、难调、难改。建议每层只做一件事：
- 最内层：专注原始数据清洗，比如去重、补空值、统一编码、过滤无效记录（如 status != 'deleted'）
- 中间层：完成单维度聚合或关联，比如按部门统计销售额、关联用户表补姓名和部门ID
- 外层：负责最终呈现逻辑，比如计算同比环比、打标签（高价值客户/流失预警）、排序分页
例如统计“各城市近30天新客订单金额TOP3”，内层查订单+用户注册时间，中间层按城市+日期聚合，外层用ROW_NUMBER()分组排序取TOP3——三层各司其职，比一个超长嵌套可读性强得多。
优先用CTE替代深层嵌套，提升可维护性
WITH语句（CTE）本质是命名的临时结果集，逻辑上等价于子查询，但更易读、可复用、支持递归。尤其当某段逻辑被多次引用（比如“活跃用户定义”在多个指标中都要用），CTE能避免重复写相同子查询。
示例片段：
WITH active_users AS (
SELECT user_id FROM login_log WHERE dt >= CURRENT_DATE - INTERVAL '30 days' GROUP BY user_id
),
order_summary AS (
SELECT city, COUNT(*) cnt, SUM(amount) amt
FROM orders o
JOIN active_users u ON o.user_id = u.user_id
GROUP BY city
)
SELECT city, amt, ROUND(amt / SUM(amt) OVER(), 4) share
FROM order_summary
ORDER BY amt DESC
LIMIT 10;
该用窗口函数时，别硬套嵌套
很多报表需求看似要“自连接”或“多层子查询”，其实是典型的窗口场景：比如“每个品类下销量最高的商品”“累计到当前月的GMV”“对比上期增长”。强行用嵌套实现，代码冗长且性能差；用ROW_NUMBER()、SUM() OVER()、LAG()等，一行解决。
- 要排名？用 ROW_NUMBER() OVER (PARTITION BY category ORDER BY sales DESC)
- 要累计？用 SUM(sales) OVER (ORDER BY month ROWS UNBOUNDED PRECEDING)
- 要对比上期？用 LAG(sales, 1) OVER (ORDER BY month)
这类计算放在外层SELECT里即可，无需额外子查询包裹，结构立刻扁平化。
关联顺序与过滤时机，直接影响性能和结果
嵌套层级多，常因JOIN顺序或WHERE位置出错。记住两个原则：
- 尽早过滤：在最靠近数据源的层级加WHERE（比如在子查询里就加上 date >= '2024-01-01'），避免无谓的数据膨胀
- 小表驱动大表：若需LEFT JOIN一个维表（如地区表），确保主表已通过条件筛到合理量级，否则左表全量JOIN会拖慢整个链路
- 注意NULL陷阱：LEFT JOIN后在WHERE里写维表字段条件（如 WHERE region.name = '华东'），实际会退化为INNER JOIN——应把条件移到ON里或用COALESCE处理
不复杂但容易忽略。
