窗口函数配合条件累计求和计算阶梯提成，需先按员工和时间排序，用SUM() OVER(ORDER BY ... ROWS UNBOUNDED PRECEDING)计算累计销售额，再结合CASE WHEN和阶梯规则表分段应用不同提成比例。
窗口函数怎么配合条件累计求和算阶梯提成
阶梯提成的核心是「按销售额分段，每段用不同提成比例，且累进计算」。直接用 SUM() 或 GROUP BY 会丢失明细粒度，必须靠窗口函数动态划分区间并逐行累计。关键不是写 OVER()，而是把销售记录按金额排序后，用 SUM() OVER (ORDER BY ... ROWS BETWEEN ...) 模拟手工累加过程。
- 必须先按员工+时间排序（比如
ORDER BY emp_id, sale_date），否则累计顺序错，提成全乱 - 不能只依赖
ROWS UNBOUNDED PRECEDING—— 阶梯规则要求“当前行所在档位之前所有档位的销售额”参与计算，需结合CASE WHEN判断当前行属于哪一档，再用条件聚合 - 常见错误：把提成比例直接乘在
SUM(sale_amt) OVER (...)上，结果是整段累计额按同一比例算，而非分段计价
如何用 LAG() + 条件判断定位当前销售落在哪一阶梯
单靠 SUM() OVER 只能累计金额，无法知道“当前这笔销售触发了第几档”。需要先定义阶梯边界（如 0–10万、10–30万、30万+），再用 LAG(sale_amt) OVER (PARTITION BY emp_id ORDER BY sale_date) 获取上一笔累计额，和当前档位下限比对。
- 示例阶梯配置表：
tier_rules(tier_start, tier_end, rate)，需用CROSS JOIN或LATERAL（PostgreSQL）/APPLY（SQL Server）关联到每条销售记录 - 更稳妥的做法：先用
SUM(sale_amt) OVER (PARTITION BY emp_id ORDER BY sale_date ROWS UNBOUNDED PRECEDING)算出截至当前行的累计销售额cum_amt，再用CASE WHEN cum_amt 找出适用档位 - 注意：
cum_amt是含当前行的累计值，计算本档提成时，要减去前一档上限（如第二档提成 =MIN(cum_amt, 300000) - 100000），否则会重复计入
为什么不能用 GROUP BY + 子查询替代窗口函数
有人试图用子查询对每个员工先算总销售额，再查阶梯表匹配比例——这只能得出总提成，无法拆解到每一笔销售的贡献值。业务系统常需追溯“某笔大单带来了多少额外提成”，或做销售过程激励提醒，必须保留行级结果。
-
GROUP BY emp_id后丢失销售时间序列，无法体现“早达标早享受高比例”的激励逻辑 - 子查询关联阶梯表时，若用
WHERE total_sale BETWEEN tier_start AND tier_end，会漏掉跨档情况（比如总销售额 35 万，实际是前 10 万按 5%、中间 20 万按 8%、剩余 5 万按 12%，子查询没法分段） - 性能上，窗口函数通常比多层嵌套子查询快，尤其数据量过万后，执行计划里
WindowAgg节点比多个HashJoin更可控
MySQL 8.0 / PostgreSQL / SQL Server 的语法差异点
核心逻辑一致，但细节处理不同：MySQL 8.0 支持完整窗口函数，PostgreSQL 对 RANGE 和 ROWS 区分严格，SQL Server 的 OVER 不支持直接嵌套 CASE 在 SUM() 内部。
- MySQL：可直接写
SUM(CASE WHEN ... THEN sale_amt ELSE 0 END) OVER (PARTITION BY emp_id ORDER BY sale_date) - PostgreSQL：若阶梯边界非整数（如 99999.99），建议用
RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW避免浮点排序误差 - SQL Server：需把条件累计拆成 CTE，先算
cum_amt，再在外层SELECT中用CASE分段计算，否则报错Window function cannot be used in the context of another window function
真正卡住的往往不是语法，而是没想清楚“累计额”和“本档增量额”的区别——前者是状态，后者才是提成基数。写完记得用单条高金额销售测试边界值，比如刚好卡在 10 万、30 万这些档位线上。
