SQL里的CASE表达式是很多人在学会SELECT、WHERE、GROUP BY之后最容易卡住的一个知识点。它不像JOIN那样要理解表关系也不像子查询那样要理清嵌套层级但真正写业务查询时你很快会发现只要涉及“按条件算出一个新值”的需求CASE表达式都是最直接的解法。几乎所有主流关系型数据库管理系统包括MySQL、PostgreSQL、SQL Server、Oracle都支持同一套CASE语法学会之后不需要为某个数据库单独记一套写法。下面不按语法手册的顺序讲而是按实际落地顺序把CASE表达式拆开过一遍先理解两种基础语法再逐个跑通SELECT、WHERE、ORDER BY、GROUP BY里的用法最后补上嵌套、聚合、批量更新、排错思路和面试题常见问法。如果你已经能写基本的查询但对CASE表达式的印象停留在“见过但用不熟”这一篇可以直接照着练。1. CASE表达式到底是什么为什么每个写SQL的人都要掌握1.1 从一个最简单的需求说起假设你有一张学生成绩表结构大概是这个样子CREATE TABLE student_score ( student_id INT, student_name VARCHAR(50), subject VARCHAR(20), score INT );现在业务要求60分以上显示“及格”60分以下显示“不及格”。如果没有CASE表达式大部分人的第一反应是把查询结果拉到程序里再写一个for循环做if else判断。这样当然能实现但问题也很明显数据量小的时候还好数据量大时要把所有结果集都加载到应用内存里做二次处理浪费带宽和内存。如果报表、接口、导出文件都要用到同一个等级字段每个地方都得复制同一段判断逻辑很容易漏改。很多分析场景里你根本拿不到程序代码只能用SQL直接输出结果比如BI报表、临时取数、数据库客户端查询。用CASE表达式这个需求在SQL内部就解决了SELECT student_name, score, CASE WHEN score 60 THEN 及格 ELSE 不及格 END AS grade_label FROM student_score;执行之后会多出一列grade_label完全不依赖外部程序。我第一次看到这段代码时的反应是这不就是SQL里的if else吗理解没错但需要补一个关键点CASE是表达式不是语句。它本身不修改数据不控制流程只负责根据条件返回一个值。所以它可以用在任何“能放表达式”的位置包括SELECT、WHERE、ORDER BY、GROUP BY甚至UPDATE的SET语句里。1.2 两种语法简单CASE和搜索CASECASE表达式有两种写法很多教材会区分成“简单CASE表达式”和“搜索CASE表达式”。简单CASE表达式的写法是CASE 列名 WHEN 值1 THEN 结果1 WHEN 值2 THEN 结果2 ELSE 默认结果 END它做的事情是拿“列名”和后面的每个值做等值比较。比如性别字段存的是0和1想显示成“男”“女”SELECT user_name, CASE gender WHEN 1 THEN 男 WHEN 0 THEN 女 ELSE 未知 END AS gender_label FROM users;搜索CASE表达式的写法是CASE WHEN 条件1 THEN 结果1 WHEN 条件2 THEN 结果2 ELSE 默认结果 END搜索CASE不限定某一列每个WHEN后面是一个完整的布尔表达式可以做范围判断、多列组合、甚至子查询。比如按分数范围评级SELECT student_name, score, CASE WHEN score 90 THEN 优秀 WHEN score 80 THEN 良好 WHEN score 60 THEN 及格 ELSE 不及格 END AS level FROM student_score;从使用频率上看搜索CASE比简单CASE更常用。因为等值映射在很多场景里可以用JOIN字典表替代而范围判断、组合条件往往只能靠搜索CASE来写。比较项简单CASE表达式搜索CASE表达式写法位置CASE后紧跟列名CASE后直接WHEN比较方式只能做等值比较支持范围、多列、布尔表达式典型场景字典值映射、状态码转文字成绩评级、动态条件、复杂分类灵活性较低较高1.3 先记住这几条判断标准CASE表达式看着简单真正用起来容易在“要不要用、用哪种、放在哪”上面犹豫。我给自己定的判断顺序是这样的先看这个值是不是只靠一条查询就能算出来。如果是优先考虑CASE。再看匹配条件是不是等值。固定离散值用简单CASE范围、比较、AND/OR组合用搜索CASE。最后看计算位置。展示层翻译用SELECT里的CASE过滤用WHERE里的CASE排序用ORDER BY里的CASE分组统计用GROUP BY或聚合函数里的CASE。还有一个容易被忽略的点简单CASE虽然写法短但它比较的是“等于”。如果被比较列里存在NULLNULL NULL不会返回真所以任何WHEN都匹配不上只能走到ELSE。搜索CASE可以显式写WHEN column IS NULL把NULL单独处理。这个差别在做数据清洗时非常关键。2. 从最简单的例子开始把数据翻译成人话2.1 在SELECT里做字段值映射CASE最基础、最不容易写错的用法就是SELECT里的字段映射。实际开发中最常见的是状态字段数据库里存的是数字页面上要显示中文。比如订单状态SELECT order_id, status, CASE status WHEN 1 THEN 待支付 WHEN 2 THEN 已支付 WHEN 3 THEN 已发货 WHEN 4 THEN 已完成 ELSE 已取消 END AS status_name FROM orders;这段代码的价值在于业务方要的数据在数据库查询阶段就已经处理完了不需要后端再遍历数组做二次转换。这里我建议养成加别名的习惯也就是END AS status_name。不加别名在大多数数据库里也能跑但列名会变成一大段CASE表达式在BI工具、导出Excel时非常难看。早期我也偷懒不写别名后来报表组反复来问“这列到底是什么”从那以后所有CASE都写别名。2.2 搜索CASE处理范围条件范围条件用简单CASE写不了必须用搜索CASE。最典型的场景就是成绩等级、年龄分段、金额分层。假设要按分数显示等级90到100优秀80到89良好60到79及格其他不及格SELECT student_name, score, CASE WHEN score 90 THEN 优秀 WHEN score 80 THEN 良好 WHEN score 60 THEN 及格 ELSE 不及格 END AS level FROM student_score;这段代码看起来没问题但有一个执行顺序容易被忽略**CASE的WHEN是从上往下逐个判断的碰到第一个结果为真的条件就返回后面的WHEN不再执行。**所以写范围条件时要按从大到小或从小到大的顺序排列保证逻辑清晰。如果把条件写成这样CASE WHEN score 60 THEN 及格 WHEN score 80 THEN 良好 WHEN score 90 THEN 优秀 ELSE 不及格 END结果就是90分以上的学生也会被算成“及格”。SQL不会报错但结果完全不符合业务预期。这个问题在代码评审里出现频率非常高排查的时候第一眼就要检查WHEN的顺序。2.3 ELSE不写会怎样很多人写CASE表达式时不写ELSE默认认为“没匹配到就返回NULL也没关系”。某些场景确实没关系但有两个地方要特别注意。第一个是数据统计。COUNT、SUM这类聚合函数遇到NULL会直接忽略不会报错。比如你想统计及格人数写了这样一句SELECT COUNT(CASE WHEN score 60 THEN student_id END) AS pass_cnt, COUNT(*) AS total_cnt FROM student_score;不满足条件时返回NULLCOUNT只统计非NULL的行那么这个数字刚好等于及格人数。这个写法是安全的也是推荐的一种写法。但如果你用的是SUM并且THEN后面返回0或1不写ELSE时不满足条件会返回NULLSUM遇到NULL通常会忽略结果看起来正常。可一旦你后续拿这个字段做除法NULL可能会导致最终结果变成NULL。我建议在SUM这种需要数值累加的场景里显式写ELSE 0把兜底逻辑写清楚。第二个是展示层。如果不写ELSE当数据出现预期之外的值时界面上会直接显示空白或“null”。用户看到这个结果不会认为“数据异常”而会认为是系统bug。显式写ELSE 未知至少能给下游一个明确信号这个值不在预期范围内。注意CASE表达式是否写ELSE不是语法强制要求而是业务稳定性要求。正式报表里建议默认写ELSE除非你非常确定不可能出现未匹配值。3. 进阶用法在WHERE、ORDER BY、GROUP BY里用CASE3.1 用CASE做动态排序ORDER BY后面也能放CASE表达式这个技巧在日常开发中很实用。比如任务列表里有状态字段值是“待处理”“处理中”“已完成”产品要求固定顺序处理中排最前面待处理排中间已完成排最后同一状态内再按创建时间倒序。不写CASE时你只能按状态字段的原始值排序不一定符合业务顺序。用CASE可以这样写SELECT task_id, title, status, created_at FROM tasks ORDER BY CASE status WHEN processing THEN 1 WHEN pending THEN 2 WHEN done THEN 3 ELSE 4 END, created_at DESC;这里CASE返回一个数字数字越小越靠前。多个排序条件用逗号连接先按CASE结果排再按创建时间排。相比在程序里排序这种方式能直接配合数据库的分页避免把所有数据拉到内存里再排一遍。需要多说一句如果这些排序条件来自用户输入要先做好参数校验和权限控制不要直接拼接不可控内容。这是SQL开发的基本安全要求和CASE本身无关但写动态查询时很容易忽略。3.2 用CASE做自定义分组和行转列GROUP BY后面放CASE可以按自定义逻辑分组。比如把成绩按分数段分组统计每个等级有多少人SELECT CASE WHEN score 90 THEN 优秀 WHEN score 80 THEN 良好 WHEN score 60 THEN 及格 ELSE 不及格 END AS score_level, COUNT(*) AS cnt FROM student_score GROUP BY CASE WHEN score 90 THEN 优秀 WHEN score 80 THEN 良好 WHEN score 60 THEN 及格 ELSE 不及格 END;这里有个细节SELECT里的CASE和GROUP BY里的CASE必须保持一致。有些数据库允许在GROUP BY里直接写别名GROUP BY score_level但标准SQL里更稳妥的做法是重复写完整表达式避免不同数据库行为不一致。CASE在分组统计里还有一个经典用途是行转列。假设成绩表里每行是一个学生的一门课成绩现在想把语文、数学、英语成绩放到同一行展示SELECT student_name, MAX(CASE WHEN subject 语文 THEN score END) AS chinese, MAX(CASE WHEN subject 数学 THEN score END) AS math, MAX(CASE WHEN subject 英语 THEN score END) AS english FROM student_score GROUP BY student_name;这段SQL的核心逻辑是先用CASE WHEN subject 语文 THEN score把语文成绩挑出来其他科目返回NULL再在外面套MAX让同一学生的多行数据合并成一行同时忽略NULL。用MIN或SUM也可以但因为成绩是单值MAX和MIN的语义是“取那个非NULL值”。如果希望没有成绩的科目显示0而不是NULL可以把ELSE写成0MAX(CASE WHEN subject 语文 THEN score ELSE 0 END) AS chinese但这里要注意区分业务含义NULL表示“该学生没有这条记录”0表示“语文成绩确实是0”。两者不能混为一谈。我更建议在行转列时保留NULL等数据进入报表层再决定怎么展示。3.3 用CASE处理NULL和空字符串数据清洗是CASE表达式的另一个主场。数据库里经常会出现两种“空”一种是NULL表示没有值另一种是空字符串表示录入了空内容。业务上往往要区别对待。比如客户表里手机号字段可能是NULL也可能是空字符串。现在要展示成一段说明文字SELECT customer_id, CASE WHEN phone IS NULL THEN 手机号未录入 WHEN phone THEN 手机号为空字符串 ELSE phone END AS phone_status FROM customers;这里顺序很重要一定要先判断IS NULL再判断等于空字符串。如果反过来先写phone NULL行不会满足这个条件会继续往下走最后落到ELSE。逻辑上有点绕但SQL对NULL的判断就是这样任何和NULL做等值比较的结果都是“未知”不会返回TRUE。如果需求只是“把NULL和空字符串统一显示成未填写”可以简化成CASE WHEN COALESCE(phone, ) THEN 未填写 ELSE phone ENDCOALESCE先把NULL转成空字符串再判断是否为空。这是一种有效的简化但对新手来说可读性稍差。我建议先用完整写法确保每一步都看得明白再考虑简化。4. 再复杂一点的场景聚合、嵌套、UPDATE和去重4.1 CASE与聚合函数配合做条件统计条件统计是CASE表达式在报表场景里最常用的组合。比如统计成绩表里优秀人数、及格人数、不及格人数一次查询全部算出来SELECT COUNT(CASE WHEN score 90 THEN 1 END) AS excellent_cnt, COUNT(CASE WHEN score 60 AND score 90 THEN 1 END) AS pass_cnt, COUNT(CASE WHEN score 60 THEN 1 END) AS fail_cnt FROM student_score;这里使用COUNT只统计非NULL行的数量。满足条件时返回1不满足时返回NULL所以最终数字就是满足条件的行数。也可以使用SUMSUM(CASE WHEN score 90 THEN 1 ELSE 0 END) AS excellent_cnt两种写法结果一样。区别在于COUNT不写ELSE看起来更简洁SUM必须配合ELSE 0否则不满足条件时返回NULL后续计算可能被NULL污染。我个人在统计场景更倾向于用SUM(CASE WHEN ... THEN 1 ELSE 0 END)因为返回值类型更固定不容易出现NULL传播的问题。4.2 嵌套CASE什么时候值得用CASE表达式可以嵌套也就是在一个THEN或WHEN里再写一个CASE。例如按分数和补考次数综合评价SELECT student_name, score, makeup_count, CASE WHEN score 60 THEN CASE WHEN makeup_count 0 THEN 正常通过 ELSE 补考通过 END ELSE 未通过 END AS final_result FROM student_score;这个嵌套逻辑本身没问题但读起来已经有点费力。原因是CASE和WHEN的数量一多人眼很难快速匹配每个分支。我的建议是嵌套最多控制在两层如果业务规则更复杂优先拆成子查询或CTE先计算出一个中间字段再在外部查询里写CASE。比如上面的需求可以先用一个子查询算出考试类型再在外层评级WITH score_info AS ( SELECT student_name, score, makeup_count, CASE WHEN makeup_count 0 THEN 正常 ELSE 补考 END AS exam_type FROM student_score ) SELECT student_name, score, CASE WHEN score 60 AND exam_type 正常 THEN 正常通过 WHEN score 60 AND exam_type 补考 THEN 补考通过 ELSE 未通过 END AS final_result FROM score_info;这种写法多写了几行SQL但每一层只解决一个问题后期维护时不需要展开一长串嵌套CASE。生产环境里清晰比炫技重要。4.3 在UPDATE里用CASE做批量条件更新CASE表达式不仅能用于查询也能用在UPDATE语句里实现一次更新多条记录的不同状态。比如订单超过7天未支付自动把状态改成“已取消”已经支付的订单状态改成“处理中”其他情况保持不变UPDATE orders SET status CASE WHEN status 1 AND DATEDIFF(NOW(), created_at) 7 THEN 5 WHEN status 2 THEN 3 ELSE status END WHERE order_id IN (101, 102, 103, 104, 105);这个写法的价值在于避免对同一张表执行多次UPDATE减少事务次数和锁等待。如果不加ELSE status那么不满足条件的记录会把status更新成NULL这通常是灾难性的。所以这里ELSE status不是可选项而是必须写的保护逻辑。4.4 用CASE做去重统计CASE和COUNT(DISTINCT ...)组合可以完成带条件的去重统计。比如统计“有有效手机号的用户数”手机号非空且长度合理才算有效SELECT COUNT(DISTINCT CASE WHEN phone IS NOT NULL AND LENGTH(phone) 11 THEN user_id END) AS valid_user_cnt FROM customers;这个查询的逻辑是满足条件时返回user_id不满足时返回NULLCOUNT(DISTINCT ...)会先忽略NULL再对剩余user_id去重。这是统计有效用户、活跃用户时很常见的写法。使用这个组合时要注意CASE返回的字段类型要和DISTINCT匹配不能一会返回数字一会返回字符串如果user_id数据量很大去重统计会消耗较多资源建议先通过WHERE把无关数据过滤掉再丢给COUNT(DISTINCT ...)不要全表硬扛。5. 容易被坑的地方和排查思路5.1 类型不一致导致报错或结果异常CASE表达式的所有THEN分支返回类型尽量保持一致。比如一个分支返回字符串另一个分支返回数字不同数据库有不同处理方式有些数据库会做隐式转换把数字转成字符串或反过来结果看起来能用但可能丢失精度。有些数据库直接报错提示类型不一致。最典型的错误是数字和字符串混用CASE WHEN status 1 THEN 正常 WHEN status 2 THEN 0 END这段代码在不同数据库里表现不一样但都不推荐。正确做法是统一返回类型比如都返回字符串或者都返回数值。排查这类问题第一步不是盯着SQL看而是先看完整报错信息。数据库通常会把出错的表达式和位置一起输出。把CASE每个分支的返回值列出来对比目标字段类型就能定位到是哪个分支出了问题。5.2 逻辑顺序错误导致结果不对这是CASE表达式最常见、最隐蔽的问题。SQL不会报错但结果和预期不符。核心逻辑是CASE从上到下匹配WHEN遇到第一个为真的条件就返回不再继续判断。所以写范围条件时顺序必须统一。比如CASE WHEN score 60 THEN 及格 WHEN score 90 THEN 优秀 ELSE 不及格 END这个查询永远不会返回“优秀”因为90分也满足score 60在第一个WHEN就被截住了。排查这种问题不要先怀疑数据库先把WHEN条件列出来按从大到小或从小到大排一遍再用一条边界数据手动走一遍流程很快就能发现。我一般会拿三条边界数据测试最小值、分界值、最大值。比如成绩表里取60分、90分、59分三条记录分别检查映射结果是否符合预期。边界值能覆盖大部分WHEN顺序问题。5.3 性能到底受不受影响很多新手担心使用CASE会拖慢查询。实际上在SELECT和ORDER BY里使用CASE表达式通常不会造成严重性能问题尤其是在数据量不大的报表场景。真正需要关注的是下面几种情况在WHERE条件里用CASE包裹字段比如CASE WHEN score 60 THEN 1 ELSE 0 END 1这类写法会让优化器难以使用字段上的索引。遇到这种情况尽量改写成score 60。行转列时使用MAX(CASE WHEN ... END)如果表很大且没有合适索引需要检查执行计划。嵌套CASE层级过深会增加SQL解析和优化成本但通常不是查询瓶颈。更实际的问题是维护成本。排查性能问题正确顺序是先看单条查询耗时是否真的达到瓶颈。再看执行计划找到消耗最大的节点。然后检查是索引、扫描行数、连接顺序还是CASE表达式本身导致的问题。最后根据优化器建议调整而不是盲目删除CASE。把问题归因到CASE之前一定要先看执行计划。很多时候真正的瓶颈是全表扫描、缺失索引或JOIN条件写错CASE只是背锅。现象常见原因先检查什么结果全部落在某一个分支WHEN顺序不对用边界值数据手动走一遍返回类型报错分支类型不一致每个THEN的返回值类型查询速度慢索引失效或全表扫描执行计划结果显示NULL或空白没有ELSE或NULL判断顺序不对检查输入数据和WHERE条件6. 面试题、实战案例和CASE表达式的边界6.1 成绩评级题把WHEN顺序当作第一考点面试里最常见的CASE题目是这样的给一个成绩字段要求显示“优秀、良好、及格、不及格”。参考答案SELECT student_name, score, CASE WHEN score 90 THEN 优秀 WHEN score 80 THEN 良好 WHEN score 60 THEN 及格 ELSE 不及格 END AS grade FROM student_score;这道题考察的其实不只是语法而是WHEN顺序。如果先写 60后面所有高分段都不会命中。面试官还会追问“不写ELSE会怎样”答案是没有匹配时返回NULL这在聚合统计里可能被静默忽略。6.2 订单行转列固定列用CASE动态列换思路另一个高频面试题是订单按月统计并转成列。假设订单表有订单日期和金额要统计1到3月每个月的销售额并输出成三列SELECT SUM(CASE WHEN MONTH(order_date) 1 THEN amount ELSE 0 END) AS jan_sales, SUM(CASE WHEN MONTH(order_date) 2 THEN amount ELSE 0 END) AS feb_sales, SUM(CASE WHEN MONTH(order_date) 3 THEN amount ELSE 0 END) AS mar_sales FROM orders WHERE order_date 2025-01-01 AND order_date 2025-04-01;这个写法在面试里很标准也适合固定月份报表。但生产环境里如果月份是动态变化的我不建议硬编码列名。因为每来一个月就要改一次SQL维护成本高。更稳妥的方案是先用普通GROUP BY month查询由报表工具或程序侧完成列转换或者使用数据库自带的透视功能。这个例子很好地说明了一个边界CASE表达式适合写“列结构固定”的转换不适合写“列结构会变化”的场景。6.3 实际项目里CASE表达式的定位CASE表达式在真实项目里的定位可以概括成三类数据翻译把数据库里的状态码、类型值映射成可读文字。条件计算在查询内部完成评级、分类、归属、条件统计。结构转换配合聚合函数做行转列、条件去重、透视统计。它不适合承担的工作也需要想清楚非常复杂的业务规则、需要循环和游标的操作、需要访问外部系统或接口的逻辑、需要长期维护的复杂分支判断。这些应当放在程序代码、存储过程或专业报表工具里而不是全部压进一条SQL。我见过不少同事把一大段嵌套CASE当成万能方案最后SQL写得又长又难读。其实很多分支逻辑拆成子查询和CTE后反而更清晰。真正能写高质量SQL的人不是会更多关键字而是知道什么逻辑该放在SQL层什么逻辑不该放。这条经验也适合所有刚接触CASE表达式的读者先在小查询里把语法跑通再逐步尝试WHERE、ORDER BY、GROUP BY、行转列和聚合统计。单条任务跑稳之后再处理批量报表和复杂业务思路会清晰很多。