CASE必须位于BEGIN...END内，仅用于赋值、INSERT/UPDATE字段值或返回值计算；须用搜索CASE处理范围判断，注意条件顺序、类型一致性和ELSE不可省略；推荐在单条DML中使用以提升性能与可维护性。
存储过程中CASE必须写在BEGIN...END内，不能独立存在
存储过程里用CASE不是直接贴SQL语句就行——它必须嵌套在BEGIN和END之间，且只能出现在合法表达式上下文中，比如赋值、插入字段、返回值计算等位置。常见错误是把CASE当独立语句写在BEGIN外，或试图在DECLARE段直接用它定义变量类型，这会导致语法报错：Incorrect syntax near 'CASE'。
实际使用时，CASE通常用于：
- 给局部变量赋值：
SET @status_desc = CASE WHEN @score >= 90 THEN 'A' ELSE 'B' END; - 构造动态INSERT/UPDATE的字段值，例如按订单金额分级标记：
INSERT INTO order_summary (...) VALUES (... , CASE WHEN @amount > 1000 THEN 'VIP' ELSE 'NORMAL' END); - 配合
IF或循环做分支逻辑前置判断，避免冗余条件重复写
搜索CASE比简单CASE更适合业务规则判断
业务规则往往不是“等于某个值”，而是“大于某阈值”“在某区间”“满足多个AND/OR组合”。这时候必须用搜索CASE（即CASE WHEN condition THEN ...），而不是简单CASE（CASE column WHEN value THEN ...）。后者只支持等值匹配，一遇到范围判断就失效。
例如处理客户等级逻辑：
SET @level = CASE WHEN @total_order_amt >= 50000 THEN 'PLATINUM' WHEN @total_order_amt >= 20000 THEN 'GOLD' WHEN @total_order_amt >= 5000 THEN 'SILVER' ELSE 'BRONZE' END;
注意点：
- 条件顺序不能颠倒，否则高阈值规则被低阈值覆盖
- 所有
THEN后的返回值类型要一致（如全为VARCHAR，不能混用INT和NULL） -
ELSE不能省略，否则@level可能为NULL，后续逻辑出错难定位
在UPDATE或INSERT中直接用CASE可减少多条SQL
别再写一堆IF @x > 100 BEGIN UPDATE ... END ELSE BEGIN UPDATE ... END——在单条UPDATE或INSERT里用CASE更简洁、原子性更强。
比如更新用户状态时，根据积分和最后登录时间复合判断：
UPDATE users SET status = CASE WHEN points >= 10000 AND last_login > DATEADD(day, -30, GETDATE()) THEN 'ACTIVE_PREMIUM' WHEN points >= 1000 AND last_login > DATEADD(day, -90, GETDATE()) THEN 'ACTIVE' ELSE 'INACTIVE' END WHERE user_id = @uid;
优势：
- 一次执行完成，避免多次IO和锁竞争
- 逻辑集中，修改规则只需改一处
- 数据库引擎能更好优化执行计划（相比多分支IF）
坑点：如果CASE里引用了子查询（如WHEN (SELECT COUNT(*) FROM orders WHERE user_id = @uid) > 5），性能会明显下降，应提前算好变量再参与判断。
跨数据库兼容性差，别在CASE里用方言函数
CASE本身是SQL标准，但嵌套的函数不是。比如GETDATE()（SQL Server）、NOW()（MySQL）、SYSDATE（Oracle）混用会导致迁移失败；ISNULL()、COALESCE()、NVL()也各不相同。
稳妥做法：
- 所有日期函数统一用
CURRENT_TIMESTAMP（标准SQL） - 空值处理统一用
COALESCE()（比ISNULL更通用） - 字符串拼接避免
+（SQL Server）或CONCAT()（MySQL 5.7+），改用||（标准）或明确标注数据库方言
最易被忽略的是：不同数据库对CASE中数据类型隐式转换的容忍度不同。SQL Server允许WHEN 1 THEN 'OK' ELSE 0，但PostgreSQL会报错，必须显式转成同一类型。
