应优先用 CASE 表达式替代 IF 嵌套处理值计算逻辑，如状态转换、分级打标；IF 保留用于流程控制（RETURN、INSERT 等）。CASE 适用于 SELECT/WHERE/ORDER BY 等表达式上下文，但 WHERE 中滥用会导致索引失效。
IF 嵌套太多导致存储过程难读难维护
SQL Server 里写一堆 IF …… BEGIN …… END 嵌套，逻辑一深就晕，改个条件要翻三页，还容易漏掉 ELSE 分支。这不是语法问题，是结构问题——用 CASE 表达式替代控制流，能把判断逻辑从“执行路径”变成“值计算”，更接近数据思维。
适用场景：需要根据字段值返回不同结果（比如状态码转中文、金额分级打标），而不是真正要跳过某段 SQL 执行。
-
CASE只能用于表达式上下文（SELECT、WHERE、ORDER BY、函数参数等），不能代替IF做流程控制（比如不满足条件就RETURN或INSERT） -
CASE是标量，返回单个值；IF是语句块，可执行多行操作 - 嵌套
CASE比嵌套IF更易被 SQL Server 优化器推导，尤其在WHERE中用CASE可能让索引失效，要小心
CASE WHEN 在 SELECT 中直接替换 IF-ELSE 逻辑
比如原写法用IF @status = 1 BEGIN SELECT '启用' END ELSE IF @status = 0 BEGIN SELECT '停用' END，其实只需一行：
SELECT CASE @status WHEN 1 THEN '启用' WHEN 0 THEN '停用' ELSE '未知' END AS status_text注意：CASE的 WHEN 子句是逐行匹配，遇到第一个真值就返回，后续不执行——这点和 IF 顺序判断一致，但写法干净得多。
- 用
WHEN+ 值匹配（简单 CASE）适合等值判断；用WHEN+ 布尔表达式（搜索 CASE）适合范围或复合条件，如WHEN @amount > 10000 THEN '大额' -
ELSE不是可选的——没写且无匹配时返回NULL，线上出空值容易埋坑 - 所有分支返回的数据类型必须兼容，SQL Server 会按数据类型优先级隐式转换，比如一个分支返回
INT、另一个返回VARCHAR，最终可能是VARCHAR，但长度取最长那个，可能截断
WHERE 里滥用 CASE 引发性能暴跌
常见错误：想动态切换过滤条件，写成 WHERE col = CASE @flag WHEN 1 THEN 'A' WHEN 2 THEN 'B' END。这会让 SQL Server 无法使用col 上的索引，因为优化器没法预判 CASE 结果。
真正该用 CASE 的地方，是把逻辑“塞进计算列”或“参与聚合”，而不是当开关用。
- 动态条件优先用
OR逻辑组合，比如WHERE (@flag = 1 AND col = 'A') OR (@flag = 2 AND col = 'B')，SQL Server 2016+ 能较好生成松散计划 - 如果必须用
CASE参与过滤，确保它出现在等号右边且不依赖参数（如WHERE col = (SELECT CASE ……)），否则基本等于放弃索引 - 在
ORDER BY里用CASE做动态排序（如ORDER BY CASE @sort WHEN 'name' THEN name END）相对安全，但要注意NULLS FIRST/LAST兼容性（SQL Server 不支持，得用IS NULL补位）
存储过程里混合用 CASE 和 IF 的关键分界点
别硬凑——什么时候该留IF，什么时候该切CASE，看动作粒度。
- 需要执行不同 SQL 语句（比如
INSERTvsUPDATE）、改变流程走向（RETURN、THROW）、或处理事务边界，必须用IF - 只是给某个字段赋值、拼接字符串、算等级、转义状态，一律用
CASE，哪怕嵌套三层也比三层IF清晰 - SQL Server 2022 开始支持
IF EXISTS (……) BEGIN …… END ELSE BEGIN …… END语法糖，但本质还是流程控制，和CASE不冲突——一个管“做什么”，一个管“是什么”
最常被忽略的是：CASE表达式里的子查询不能引用外部作用域的变量（比如 WHEN (SELECT COUNT(*) FROM t WHERE t.id = @id) > 0 在某些版本会报错），得提前算好或用 APPLY 带入。
