阶梯单价分段计算需先明确按行判断还是累计量判断：按行用CASE WHEN从高到低匹配区间并乘数量；累计量则需窗口函数加LATERAL/APPLY拆解交集；推荐用CTE或临时表管理阶梯规则，并注意精度、审计与数据库兼容性。
用 CASE WHEN 实现阶梯单价分段计算
SQL 本身不提供原生的“阶梯计价”聚合函数，必须手动拆解区间逻辑。核心思路是：对每条记录，根据其数量（或金额）落入哪个价格区间，用 CASE WHEN 映射出对应单价，再乘以该记录的实际数量。
常见错误是直接在 SUM() 外套 CASE 却忽略“同一订单跨多个阶梯”的情况——阶梯计价通常针对累计量（如采购总量达 100 件后，后续部分才按新单价算），但多数人误以为按单条记录独立判断。实际业务中，90% 的需求属于「按单条记录数量定单价」，例如：订单行数量 ≥ 50 享 9 折，≥ 100 享 85 折。
- 务必确认业务规则是「按行判断」还是「按客户/订单累计量判断」；后者需先
SUM() OVER (PARTITION BY ...)算累计值，再套CASE -
CASE条件顺序必须从高到低（如先写 ≥100，再 ≥50），否则低阈值会提前截断 - MySQL 8.0+、PostgreSQL、SQL Server 均支持；SQLite 需注意
CASE表达式嵌套深度限制
示例（按单条记录数量定单价）：
SELECT
SUM(
qty * CASE
WHEN qty >= 100 THEN 18.5 -- 每件 18.5 元
WHEN qty >= 50 THEN 19.2
ELSE 20.0
END
) AS total_amount
FROM orders;用 LATERAL / APPLY 拆解跨阶梯的累计计价
当规则是「客户年度采购累计满 1000 件后，后续所有订单按折扣价」时，单靠 CASE 不够——需要先算出每个订单的「有效计价数量」，即它在累计序列中实际落在哪个价格段内。
PostgreSQL 可用 LATERAL，SQL Server 用 APPLY，它们能将子查询结果作为当前行的“计算上下文”，从而动态算出该订单有多少数量应计入哪个阶梯。
- 先用窗口函数
SUM(qty) OVER (ORDER BY order_date ROWS UNBOUNDED PRECEDING)得到截至当前订单的累计量 - 再用
LATERAL计算该订单的“起始累计量”和“结束累计量”，与阶梯边界比对，求交集长度 - 避免用自连接模拟累计——大数据量下性能陡降，且易因排序不稳定出错
简化示意（PostgreSQL）：
SELECT SUM(price_segment.amount)
FROM orders o
CROSS JOIN LATERAL (
SELECT
GREATEST(0, LEAST(o.qty, 1000 - prev_total) * 19.0) +
GREATEST(0, LEAST(o.qty, 2000 - GREATEST(1000, prev_total)) * 17.5) AS amount
FROM (SELECT COALESCE(SUM(qty) FILTER (WHERE order_date < o.order_date), 0) AS prev_total FROM orders) t
) AS price_segment;用临时表或 CTE 预定义阶梯规则提升可维护性
硬编码在 SQL 里的阶梯（如 WHEN qty >= 100 THEN 18.5）一旦调整就需改多处，还容易漏同步。更可靠的做法是把阶梯规则抽成独立结构。
创建一个 price_tiers 表或 CTE，字段包括 min_qty、max_qty、unit_price，然后用范围 JOIN 关联原始数据。这样改价只需更新一张表，SQL 主体完全不动。
- JOIN 条件必须是
t.min_qty <= o.qty AND (t.max_qty IS NULL OR o.qty <= t.max_qty)，注意闭开区间的处理 - 若阶梯有重叠或空缺，加
COUNT(*) = 1校验或用ROW_NUMBER() OVER (PARTITION BY o.id ORDER BY t.min_qty DESC)取最高优先级匹配 - MySQL 5.7 不支持 CTE 中的递归或复杂 JOIN，此时建议用临时表 + 索引加速
警惕浮点精度与聚合顺序引发的金额偏差
阶梯计价结果常用于财务场景，但 SQL 聚合默认不保证中间计算的精度。比如 qty * unit_price 若 unit_price 是 DECIMAL(10,2)，而 qty 是整型，乘法结果可能隐式转为 FLOAT 导致 0.01 元级误差。
- 显式声明单价字段为
DECIMAL(12,4)，并在计算中用CAST(... AS DECIMAL(18,4))强制精度 - 避免先
SUM(qty)再乘单价——这等于把所有数量压进一个阶梯，违背阶梯本意 - Oracle 用户注意
NUMBER类型默认精度足够，但显式写NUMBER(18,4)更安全
真正麻烦的是审计要求：必须保留每笔明细的计价过程。这时候不能只返回 SUM()，得用 JSON_OBJECT 或字符串拼接把各段计算逻辑存下来，否则查账时无法还原。
