CASE函数是SQL Server中唯一能安全实现阶梯式报价计算的原生方案，因其可基于原始字段原子性计算、避免二次打折、确保条件互斥且覆盖全量数据，而多个UPDATE易导致数据不一致，嵌套IIF不支持、应用层计算破坏一致性。
CASE 函数是 SQL Server 中唯一能安全实现阶梯式报价计算的原生方案，其他方式（如嵌套 IIF、多次 UPDATE、应用层计算）要么不支持、易出错，要么破坏数据一致性。
为什么不能用多个 UPDATE 语句分步更新
阶梯式报价常需按金额区间执行不同系数：比如订单额 1000 元打 95 折，1000–5000 打 9 折，>5000 打 85 折。若写成两个 UPDATE：
UPDATE Orders SET price = price * 0.95 WHERE amount < 1000; UPDATE Orders SET price = price * 0.9 WHERE amount BETWEEN 1000 AND 5000;
问题立刻出现：amount = 1000 的订单先被第一条语句跳过，再被第二条命中 → 正确；但若某订单原 amount = 5200，却被误标为 5000，它先被第二条语句处理（变成 4500），之后又因 4500 落入第二区间，再次触发第二条语句 → 重复打折。根本原因是：UPDATE 不具备原子条件判断能力。
- 每次
UPDATE都基于当前行值重算，不是原始值 - 顺序敏感，无法保证“只匹配一次”
- 并发下极易产生竞态，结果不可预测
CASE 搜索函数必须用 WHEN...THEN...ELSE 结构
阶梯计算必须用搜索型 CASE（即 CASE WHEN condition THEN result），不能用简单型（CASE column WHEN value THEN result），因为区间判断无法用等值匹配。
正确写法示例（按原始 amount 计算折扣后价格）：
SELECT order_id, amount,
CASE
WHEN amount > 5000 THEN amount * 0.85
WHEN amount >= 1000 THEN amount * 0.9
ELSE amount * 0.95
END AS final_price
FROM Orders;- 条件必须从高到低或从低到高严格排序，否则会漏判（例如把
>5000放在最后，6000就会先进入>=1000分支） -
ELSE不可省略——没有ELSE时，不满足任一WHEN的行会返回NULL，导致final_price为空 - 所有
THEN后的表达式必须类型兼容，SQL Server 会取隐式转换后的最高优先级类型（如混合INT和DECIMAL，结果为DECIMAL）
在 UPDATE 中复用原始字段值做阶梯计算
如果要直接更新表中 discounted_price 字段，仍需基于原始 amount 计算，而非当前 discounted_price 值：
UPDATE Orders SET discounted_price = CASE WHEN amount > 10000 THEN amount * 0.8 WHEN amount > 5000 THEN amount * 0.85 WHEN amount > 1000 THEN amount * 0.9 ELSE amount * 0.95 END;
- 所有判断都作用于
amount，不是discounted_price—— 这是避免“二次打折”的关键 - WHERE 子句不是必需的，但加
WHERE amount IS NOT NULL可避免对空值行做无意义计算 - 若表很大，建议在
amount列上建索引，加速WHEN条件过滤
容易被忽略的 NULL 和边界陷阱
实际业务中，amount 为 NULL、或区间边界存在“等于谁”的歧义，是最常引发错误的地方：
-
CASE中任何与NULL的比较（如amount >= 1000）结果为UNKNOWN，不会命中WHEN，最终走ELSE；若没写ELSE，就变NULL - 区间定义必须无重叠、无缺口，推荐统一用左闭右开：例如
WHEN amount >= 5000 AND amount ，比 <code>BETWEEN 5000 AND 9999更可控 - 浮点数金额慎用
=判断边界，优先用范围（>=/）避免精度误差
真正棘手的不是语法，而是把业务规则准确映射成互斥、完备的布尔条件——这一步出错，后面全错。
