窗口函数分箱是用NTILE、PERCENT_RANK等为每行动态打标签（如四分位），保留原始明细；GROUP BY则压缩多行为一行，丢失明细。
什么是窗口函数分箱，和普通 GROUP BY 有什么区别？
窗口函数分箱不是把数据“压缩”成一行，而是给每行打上一个动态计算出的分组标签（比如 quartile、decile、ntile），同时保留原始明细。这在做销售排名分层、客户价值分群、同比环比对比时特别有用——你既要看单笔订单金额，又要知道它落在全量销售的哪个百分位区间。
普通 GROUP BY 会丢失明细；而 NTILE()、PERCENT_RANK()、NTILE(4) OVER (ORDER BY amount) 这类写法，是在不聚合的前提下完成逻辑分箱。
用 NTILE() 做等频分箱（比如四分位、十分位）
NTILE() 是最常用的分箱函数，它把有序结果集尽量平均分成 N 组，每组行数相差最多为 1。注意：它不看数值大小分布，只看排序后的位置。
常见错误现象：
- 数据总行数不能被 N 整除时，前几组会多 1 行，容易误判“第 1 组 = 最低 25%”是否严格成立
- 如果有大量重复
amount值，NTILE(4) OVER (ORDER BY amount)可能把相同金额拆到不同分箱里（因为窗口函数内部按物理顺序补位）
实操建议：
- 先用
COUNT(*)确认总行数，判断NTILE(10)是否真能代表“每组约 10%” - 若需严格按数值边界分箱（如 0–1000、1000–5000），改用
CASE WHEN+ 聚合统计边界值，而不是依赖NTILE - 示例：给销售订单按金额从低到高分为 5 档
SELECT order_id, amount, NTILE(5) OVER (ORDER BY amount) AS sales_tier FROM sales;
用 PERCENT_RANK() 和 CUME_DIST() 判断相对位置
PERCENT_RANK() 返回当前行在分组内的相对排名（0 到 1 之间，首行为 0，末行为 1）；CUME_DIST() 返回小于等于当前值的行占比（末行恒为 1）。它们比 NTILE 更反映真实分布，尤其适合识别长尾或陡峭区间。
使用场景：
- 找出累计占比达 80% 的销售门槛（帕累托分析）
- 标记“前 5% 高价值订单”，避免
NTILE(20)因整除问题漏掉边界行
参数差异：
-
PERCENT_RANK()公式是(rank - 1) / (total_rows - 1)，所以只有 1 行时返回0 -
CUME_DIST()是number_of_rows_preceding_or_equal / total_rows，对重复值更友好
示例：标记超过 95% 累计占比的订单
SELECT order_id, amount,
CUME_DIST() OVER (ORDER BY amount) AS cum_pct
FROM sales
WHERE CUME_DIST() OVER (ORDER BY amount) > 0.95;分箱结果用于后续过滤或 JOIN 时的坑
窗口函数不能直接出现在 WHERE 或 ON 子句中——因为执行顺序是 WHERE → GROUP BY → HAVING → SELECT → ORDER BY，而窗口函数在 SELECT 阶段才计算。
容易踩的坑：
- 写
WHERE NTILE(4) OVER (...) = 1→ 报错invalid window function reference - 在子查询里没加别名，导致外层无法引用分箱列
- 对
NULL值未处理，ORDER BY amount默认把NULL排最前，可能让“最低档”全是空值
实操建议：
- 必须用子查询或 CTE 包一层
WITH sales_with_tier AS ( SELECT *, NTILE(4) OVER (ORDER BY amount) AS tier FROM sales ) SELECT * FROM sales_with_tier WHERE tier = 1;
- 显式控制
NULL排序：用ORDER BY amount NULLS LAST（PostgreSQL/Oracle）或COALESCE(amount, -1)（MySQL 兼容）
窗口函数分箱真正的复杂点不在语法，而在业务定义是否清晰：你想要的是“等频分组”还是“等宽分组”，是否容忍重复值跨箱，以及下游是否依赖该分箱结果做聚合——这些决定了该选 NTILE、PERCENT_RANK，还是干脆放弃窗口函数、先算边界再 CASE。
