SQL报表核心是准确翻译业务逻辑，需明确定义（如复购率口径）、分步构建（CTE拆解）、处理脏数据（NULL/重复/时区/性能）并考虑自动化（视图、调度、注释、参数化）。
SQL业务报表生成，核心不是写对一条SELECT，而是把业务逻辑准确“翻译”成可执行、可维护、能应对变化的查询语句。真实场景中，报表往往要跨多表关联、处理空值、聚合分组、动态时间窗口、去重统计、条件分流（比如“新客/老客”），甚至嵌套计算指标（如复购率 = 复购用户数 / 活跃用户数）。下面用一个电商业务的真实小案例，带你一步步拆解复杂查询的思考路径。
明确业务口径：先聊清楚“复购率”到底指什么
很多同学一上来就写GROUP BY，结果跑出来数字和运营对不上——问题常出在定义模糊。比如“近30天复购率”，需确认：
- “复购”是指同一用户下单≥2次？还是购买≥2个不同商品？
- “近30天”是按订单创建时间，还是支付成功时间？是否包含退款订单？
- 分母是这30天内所有下单用户，还是首次下单发生在30天内的新客？
真实项目中，我们和业务方对齐后确定：复购 = 同一用户在近30天内完成≥2笔**支付成功**的订单；分母 = 近30天内有至少1笔支付成功的用户总数。这个口径直接决定后续JOIN方式和过滤条件。
分步构建中间结果：别想一口吃成胖子
面对“用户→订单→支付状态→时间范围→计数→比率”的链条，建议拆三步写：
-
第一步：筛出有效订单
SELECT user_id FROM orders WHERE pay_status = 'success' AND pay_time >= CURRENT_DATE - INTERVAL '30 days'; -
第二步：算每个用户的订单数 & 是否复购
WITH user_orders AS (SELECT user_id, COUNT(*) AS order_cnt FROM (...) GROUP BY user_id),
rebuy_flag AS (SELECT user_id, CASE WHEN order_cnt >= 2 THEN 1 ELSE 0 END AS is_rebuy FROM user_orders) -
第三步：汇总比率
SELECT SUM(is_rebuy)*1.0 / COUNT(*) AS repurchase_rate FROM rebuy_flag;
用CTE分层，逻辑清晰，每步可单独验证结果，也方便后续加维度（比如按城市、渠道分组）。
处理常见坑点：NULL、重复、时区、性能
真实数据永远比demo脏：
- 用户ID为空？ 加 WHERE user_id IS NOT NULL，否则COUNT(*)会把NULL当有效用户统计。
- 一笔订单多次支付成功？ 订单表和支付表是一对多，直接JOIN可能重复计数——要么用DISTINCT user_id，要么先聚合支付表再JOIN。
- 数据库时区 vs 业务时区？ pay_time存的是UTC，但业务要看北京时间（UTC+8），得写 pay_time AT TIME ZONE 'UTC' AT TIME ZONE 'Asia/Shanghai'。
- 跑太慢？ 给 pay_time 和 pay_status 加联合索引；大表关联前先WHERE过滤，别等JOIN完再WHERE。
从报表到自动化：SQL只是起点
写好SQL只是第一步。真实业务中，你还要考虑：
- 把SQL封装成视图或物化视图，供BI工具直连（避免每次改SQL都动报表）
- 用调度工具（如Airflow）每天凌晨跑一次，存入报表宽表，附带执行时间、记录数、异常告警
- 给字段加中文注释（COMMENT ON COLUMN），不然半年后你自己都看不懂“uv_7d_lag3”是什么意思
- 留一个“调试模式”参数（比如传入${date}），方便运营临时查某天数据，不用改代码
基本上就这些。复杂报表不靠炫技，靠定义准、拆得清、防得住。写完多问一句：“如果明天业务规则变一下，这段SQL改几处？”——答案越少，说明设计越稳。
