累计百分比本质是“当前行及之前累计值 ÷ 全表总计”，需先用sum() over(order by... rows unbounded preceding)算累计值，再除以全局sum(amount)（非窗口函数），排序字段须明确，分母需防0，且过滤应在计算后进行以保基准统一。

用 SUM() OVER() 计算累计金额再除以总和

累计百分比本质是「到当前行为止的累计值 ÷ 全表总计」，不能直接对百分比做窗口求和。常见错误是写成 SUM(percent) OVER(ORDER BY ...)，这毫无业务意义——你不是在累加百分比，而是在累加“占比”，逻辑崩了。

正确做法分两步：先用 SUM(amount) OVER(ORDER BY customer_id ROWS UNBOUNDED PRECEDING) 算出累计金额；再用子查询或 CTE 拿到全表 SUM(amount) 总计值；两者相除即得累计百分比。

• 排序字段（如 customer_id 或 revenue DESC）必须明确，否则窗口顺序不确定，结果不可复现
• 推荐用 ROWS UNBOUNDED PRECEDING 而非默认的 RANGE，避免因排序键重复导致意外聚合（尤其用金额排序时）
• 除法前务必检查总计是否为 0，否则触发除零错误 —— 可用 NULLIF(total, 0) 包裹分母

避免用 COUNT(*) OVER() 替代总计分母

有人误以为客户数固定，就用 COUNT(*) OVER() 当分母来算“客户占比累计”，这是典型目标错位：核心客户识别依赖的是**贡献金额的集中度**，不是客户数量的线性分布。比如 Top 20% 客户占 80% 收入，和 Top 20% 客户数占 20% 是两回事。

若真要分析客户数量维度的累计覆盖，分母必须是 COUNT(*) 总数，且分子得是 COUNT(*) OVER(...) —— 但此时已不属于“核心客户识别”场景，而是用户渗透分析。

• 金额类累计百分比：分母永远是 SUM(amount) 全局标量，不是窗口函数
• 用 COUNT(*) OVER() 做分母，SQL 虽能跑通，但数值无业务解释力
• PostgreSQL / SQL Server 支持 SUM(amount) OVER()（空 ORDER BY）直接得总计，但 MySQL 8.0+ 才支持；兼容写法仍是子查询或 CTE

处理并列排名时的累计百分比跳变

当多个客户金额相同时（例如都为 ¥50,000），按 amount DESC 排序会产生并列。窗口函数仍逐行计算累计值，但业务上常希望“相同金额客户视为同一梯队”，这时累计百分比不应在并列项之间跳变。

解决方法是先用 DENSE_RANK() OVER(ORDER BY amount DESC) 或 RANK() 分组，再对分组后结果聚合，最后做累计。但注意：这已脱离单行窗口计算范畴，需两层嵌套。

• 直接用 SUM() OVER() + 原始排序，会如实反映每行的累计进度（含跳变），适合精确归因
• 若要平滑梯队，必须在外部按金额去重或分组，例如：SELECT amount, SUM(amount) FROM (SELECT DISTINCT amount, ...)
• MySQL 中 DENSE_RANK() 与窗口 SUM() 混用需注意执行顺序：窗口函数在 GROUP BY 后失效，必须用 CTE 提前固化排名

在 WHERE 中过滤后再算累计百分比？小心基数变化

如果先 WHERE status = 'active' 再算累计百分比，分母变成活跃客户的总额，而非全量客户总额——这改变了基准，结果只能叫“活跃客户内部的累计贡献占比”，无法回答“这些活跃客户在整个业务中是不是核心”。

真正识别核心客户，通常需要**全量客户池为分母**，再叠加条件看其中多少属于活跃/高价值等子集。也就是说，过滤应放在最外层，而不是窗口计算之前。

• 错误写法：SELECT ... FROM t WHERE active=1 ORDER BY rev DESC; -- 然后算累计 → 分母变小，Top 10% 可能只占全量的 5%
• 正确写法：CTE 先算全量总计，主查询 LEFT JOIN 或子查询引用该总计，再用 WHERE 过滤展示行
• BI 工具里拖拽筛选器时，默认会下推到 SQL 的 WHERE，务必确认其是否影响了分母计算逻辑

累计百分比看着简单，但分母来源、排序稳定性、过滤时机这三点一动，业务含义就全偏了。尤其是把“活跃客户累计占比”直接当成“全局核心客户识别指标”，线上策略可能因此误伤长尾客户。