group by 后直接写 sum(case when ...) 是最稳的 kpi 拆解方式，可一次性按多维分组计算新客数、复购率等指标，避免 where 过滤丢失分组内差异或 join 性能损耗。
GROUP BY 后直接写 SUM(CASE WHEN ...) 是最稳的 KPI 拆解方式
想按部门、月份、产品线等维度自动算 KPI（比如“新客数”“复购率”“客单价”），别依赖子查询或多次 JOIN。用 CASE WHEN 套在聚合函数里，配合 GROUP BY 一次出结果，既快又可读。
常见错误是把条件判断写在 WHERE 里——那会先过滤整行，导致“复购用户”和“新客用户”无法共存于同一分组；或者用多个 LEFT JOIN 子查询，性能差还容易漏空组。
-
SUM(CASE WHEN order_type = 'new' THEN 1 ELSE 0 END)算新订单数，不是COUNT(*) WHERE order_type = 'new' - 复购率这类比率，必须用
ROUND(1.0 * COUNT(CASE WHEN is_repeat = 1 THEN 1 END) / NULLIF(COUNT(*), 0), 3)，NULLIF防除零 - 如果 KPI 依赖窗口逻辑（如“近7天滚动新客”），
GROUP BY本身做不到，得先用ROW_NUMBER()或LAG()预处理
日期维度要提前规整，别在 GROUP BY 里硬套 DATE_FORMAT(now(), '%Y-%m')
直接在 GROUP BY 里写 DATE_FORMAT(order_time, '%Y-%m') 看似方便，但会导致索引失效、时区错乱、跨年计算异常。正确做法是：在 SELECT 和 GROUP BY 中统一用预计算字段，或用标准日期截断函数。
- MySQL 推荐用
YEAR(order_time) AS year, MONTH(order_time) AS month，再GROUP BY year, month - PostgreSQL 用
EXTRACT(YEAR FROM order_time)和EXTRACT(MONTH FROM order_time) - BigQuery 用
EXTRACT(YEAR FROM order_time)或FORMAT_DATE('%Y-%m', order_time)，后者可直接用于分组且支持索引剪枝 - 避免
GROUP BY SUBSTRING(order_time, 1, 7)—— 类型不安全，字符串截取可能切到时分秒中间
多维度交叉时，GROUP BY 字段顺序不影响结果，但影响 NULL 处理逻辑
写 GROUP BY region, product_line, channel 还是 GROUP BY channel, region, product_line，对聚合值没区别。但一旦加了 ROLLUP 或 GROUPING SETS，顺序就决定哪些组合生成 NULL 占位行。
- MySQL 8.0+ 支持
GROUP BY region, product_line WITH ROLLUP，结果里product_line IS NULL表示该 region 的小计，region IS NULL AND product_line IS NULL才是总计 - PostgreSQL 要显式写
GROUPING SETS ((region, product_line), (region), ())，括号内字段顺序无关，但空元组()必须显式声明才出总计 - 所有引擎中，
GROUPING()函数才能准确判断某列的NULL是真实数据还是分组占位符，别用IS NULL直接判
当 KPI 定义含“首次”“最近一次”时，GROUP BY 本身不够，必须嵌套窗口函数
GROUP BY 只能做“本组内聚合”，没法回答“每个用户第一次下单时间是什么时候”。这类 KPI 必须先用窗口函数打标，再进 GROUP BY 统计。
- 例如“首单转化率”：先
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY create_time) AS rn，再WHERE rn = 1提取出首单记录，最后按渠道GROUP BY - “最近30天有复购的用户数”：先
MAX(order_time) OVER (PARTITION BY user_id)算出每人最新下单时间，再外层过滤max_order_time >= CURRENT_DATE - INTERVAL '30 days' - 别在
GROUP BY后用HAVING MIN(create_time) >= ...算“新用户留存”——那只是筛选分组，不是筛选原始行为事件
真正难的不是语法，是厘清 KPI 的原子行为定义：它到底基于“用户生命周期中的某个点”，还是“当前分组内的统计汇总”。前者必须前置窗口，后者才能交给 GROUP BY。
