写SQL这么多年条件判断里用得最多的就是if和case这俩。无论是做报表时把状态码翻译成中文还是写存储过程里走一堆业务分支几乎绕不开这两个关键字。刚开始学的时候我也犯迷糊IF()是个函数、CASE是个表达式、存储过程里还有个IF语句名字差不多用法却完全不一样。这篇文章就专门把这些形态掰开揉碎讲清楚配上实际业务里能直接抄的写法。如果你经常写MySQL查询、维护存储过程或者在做数据报表的SQL开发这篇文章应该能帮你少走不少弯路。1. 为什么要把条件判断写进SQL里1.1 三条最常见的业务场景先聊动机。很多人一开始不理解数据库是存数据的要加工数据在程序里算不就完了但真正写业务的时候你会发现有些操作放在SQL里做是最省事、最合理的方案。我用下来最常见的场景有三类。第一类是状态翻译。业务表里存的通常是数字编码比如订单状态0表示待付款、1表示已付款、2表示已发货。但报表要展示给人看得变成中文。这种映射关系你要是每次都在应用层写几十行if-else每张报表重复一遍维护起来非常恶心。直接在SQL里用CASE一句话映射掉报表查出来就是干净的文案。第二类是区间划分。比如根据订单金额给客户分层或者根据考试成绩划分优、良、中、差。这类需求本质上就是“给每一行数据打一个标签”if和case就是用来干这个的。第三类是条件聚合。注意这里的条件聚合和普通WHERE过滤完全不是一回事。比如你要统计每家门店“销售额超过1万的订单数”和“总订单数”如果直接用WHERE过滤掉小于1万的订单总订单数就算不出来了。这时候只能在聚合函数里写IF(条件, 1, 0)把符合条件的行为计数1来处理。这个技巧在报表里极其常用。1.2 在数据库里做和程序里做的取舍既然SQL里能写条件判断那是不是所有逻辑都塞进SQL肯定不是。我自己有个判断标准一次查询里能完成的条件加工优先在SQL里做涉及多步骤校验、需要跨表多次查询才能确认的复杂业务留给程序或者存储过程。原因很实在。第一数据量大时把所有记录拉到应用层再慢慢算网络IO和内存开销都很吓人。第二BI报表工具通常只接受一条SQL你没法在报表工具里写Java或Python逻辑。第三有些临时需求只要一条SQL就能跑出来动用程序很重。但也别走极端。比如一个业务规则极其复杂要查三张表才能判断是A还是B这种硬塞进SQL会导致一段长达几十行的CASE嵌套别人接手根本看不懂。该拆就拆。2. IF()函数与CASE表达式语法语义全拆解2.1 IF()函数MySQL里的三目运算IF()是函数形态语法就三个参数IF(expr1, expr2, expr3)expr1为真不等于0且不为NULL时返回expr2否则返回expr3。和编程语言里的三目运算符? :一个套路。比如根据员工薪资判断薪资等级SELECT emp_name, salary, IF(salary 20000, 高薪, 普通) AS salary_level FROM employee;简洁、直白这是IF()最大的优势。但它有天然的局限只能二选一。多分支时只能嵌套SELECT score, IF(score 90, 优秀, IF(score 80, 良好, IF(score 60, 及格, 不及格))) AS grade FROM exam;两层嵌套还能忍超过三层后这个SQL基本没法读了。同样的逻辑用CASE写SELECT score, CASE WHEN score 90 THEN 优秀 WHEN score 80 THEN 良好 WHEN score 60 THEN 及格 ELSE 不及格 END AS grade FROM exam;一眼看过去就知道什么意思。所以我的习惯是二选一的简单场景用IF()三选一以上的场景一律用CASE。2.2 CASE表达式的两种写法简单CASE与搜索CASECASE是SQL标准语法在其他数据库里也支持只是MySQL的用法最直观。它有两种写法。简单CASE适合等值判断语法是把一个字段放在CASE后面WHEN后面接对比值SELECT order_id, CASE order_status WHEN 0 THEN 待付款 WHEN 1 THEN 已付款 WHEN 2 THEN 已发货 WHEN 3 THEN 已完成 ELSE 已取消 END AS status_text FROM orders;这里的判断逻辑实际是order_status 0、order_status 1这样的等值匹配。要注意简单CASE只能做等值比较不能写、、LIKE这种范围或模糊匹配。搜索CASE更强WHEN后面直接跟完整条件表达式SELECT product_name, stock, CASE WHEN stock 0 THEN 缺货 WHEN stock 50 THEN 库存预警 WHEN stock 200 THEN 库存正常 ELSE 库存过剩 END AS stock_status FROM products;搜索CASE能处理比较计算、逻辑组合、模糊匹配业务上90%的场景都是这种写法。两种CASE都支持ELSE兜底ELSE可省略省略后如果所有WHEN都不匹配表达式返回NULL。这里有个必须记住的执行顺序问题WHEN条件从上到下依次判断一旦某个WHEN为真就立刻返回对应THEN的值后面剩余WHEN不再执行。这个特性既是优点也是坑后面第4节专门讲。2.3 存储过程中的IF语句完全不同的形态上面讲的IF()函数和CASE表达式都属于“表达式”作用是返回一个值写在SELECT、WHERE、UPDATE这些语句里。但存储过程、存储函数、触发器里还有另一种IF它是“流程控制语句”语法长这样IF 条件 THEN 语句; ELSEIF 条件 THEN 语句; ELSE 语句; END IF;这个IF不是用来算出一个值而是用来控制程序的走向。里面可以执行多条SQL、给变量赋值、调用其他存储过程甚至可以抛异常。我举个例子写一个简单的库存检查存储过程CREATE PROCEDURE check_stock(IN pid INT) BEGIN DECLARE current_stock INT;SELECT stock INTO current_stock FROM products WHERE product_id pid;IF current_stock 0 THEN SELECT 商品已缺货 AS stock_status; ELSEIF current_stock 50 THEN SELECT 库存偏低建议补货 AS stock_status; ELSE SELECT 库存正常 AS stock_status; END IF; END;注意这个IF是和END IF成对出现的不是CASE那种END关键字。而且存储过程中的分支里还能嵌套别的IF或循环语句。写这种IF语句时你不会把它放在普通的SELECT查询里它就是专门给过程化SQL用的。CASE能不能在存储过程里做流程控制严格说MySQL里也有CASE语句语法是CASE WHEN 条件 THEN 语句; ELSE 语句; END CASE;但实际项目中用得很少因为IF的ELSEIF语义直观得多。我自己写存储过程时几乎只认IF语句。2.4 与IF相关的几个“亲戚”函数SQL里还有一些和IF长得很像的函数容易弄混。IFNULL(a, b)如果a是NULL返回b否则返回a。它是专门处理NULL的不能用IF完全替代但意义上有点像IF(a IS NULL, b, a)。日常处理字段为NULL时设置默认值非常方便。NULLIF(a, b)如果a等于b返回NULL否则返回a。这个函数常用于防止除零错误比如COUNT(NULLIF(column, 0))也可以用于在聚合时忽略特定值。IF()和NULLIF()、IFNULL()的区别在于IF()是根据任意条件返回两个值之一后两者是针对特定情况的特殊函数。把这些放在一起理解SQL条件逻辑的小工具才算是集齐了。3. 真实业务中的实操案例3.1 用CASE做字段加工与状态翻译最基础的使用场景。假设订单表ordersorder_status是0到4的编码业务报表需要显示中文状态。SELECT order_id, order_amount, customer_id, CASE order_status WHEN 0 THEN 待付款 WHEN 1 THEN 已付款 WHEN 2 THEN 已发货 WHEN 3 THEN 已完成 WHEN 4 THEN 已取消 ELSE 未知状态 END AS status_text, CASE WHEN order_amount 10000 THEN 大额订单 ELSE 普通订单 END AS order_type FROM orders WHERE order_date 2025-01-01;这种写法把两个维度的字段加工都放在SQL里完成状态翻译用简单CASE金额分层用搜索CASE。不要小看这个映射工作直接在SQL里做完报表看板的数据源就是完全加工好的。以前见过有同事在应用层写映射函数同一套逻辑在接口、报表、导出程序里各写一遍后面状态码一调整改得头皮发麻。3.2 用IF配合聚合函数做条件统计这是我觉得MySQL条件判断里最实用的技巧之一。需求背景统计每个销售人员的订单数和大额订单数。SELECT sales_name, COUNT(*) AS total_order_cnt, SUM(IF(amount 10000, 1, 0)) AS big_order_cnt, SUM(IF(amount BETWEEN 5000 AND 9999, 1, 0)) AS mid_order_cnt, SUM(IF(amount 5000, 1, 0)) AS small_order_cnt FROM sales_order GROUP BY sales_name;原理一句话SUM里面放IF函数条件成立返回1、不成立返回0SUM累加后得到的就是“满足条件的记录数”。这种做法在报表统计里出现频率极高。用CASE写法也完全等价SUM(CASE WHEN amount 10000 THEN 1 ELSE 0 END) AS big_order_cnt我推荐写成CASE版本理由是可读性。CASE把WHEN条件、THEN值、ELSE默认值都写得很清楚别人接手时不需要理解SUM(IF(...))这个“1和0的套路”。不过这不是性能差距纯粹是代码维护习惯问题。真要二选一短代码用IF长条件用CASE。这个场景还有另一个变种用AVG(IF(...))计算满足条件的比例。比如统计“订单中金额超1万的订单占比”SELECT AVG(IF(amount 10000, 1, 0)) AS big_order_ratio FROM sales_order;AVG对1/0列求平均值结果就是比例非常巧妙。需要注意AVG的结果会自动转成DECIMAL展示比例时记得格式化。3.3 批量更新操作中的CASE妙用更新数据时经常需要对不同行的数据做不同的修改。最笨的办法是拆成多条UPDATE逐条执行但那样每一条都要扫一遍表还会出现中间状态。用CASE可以在一次UPDATE中完成批量差异化更新。比如商品表products库存紧张的商品价格上调多点库存充足的上调少点UPDATE products SET price CASE WHEN stock 50 THEN ROUND(price * 1.1, 2) WHEN stock 100 THEN ROUND(price * 1.05, 2) ELSE ROUND(price * 1.02, 2) END;这个UPDATE只会扫一遍表所有行的价格都在同一条语句内在内存中完成计算然后统一提交。对线上环境来说减少写事务的持续时间、避免逐条更新引入的间隙是很有价值的。写这类批量UPDATE时建议先跑SELECT确认条件覆盖范围看影响行数再在事务里执行。尤其是处理生产数据把WHERE条件写清楚、把CASE逻辑在SELECT里先验证一遍不要直接在生产库上试。3.4 存储过程里用IF做参数校验与流程控制存储过程是IF语句的主场。这里IF的作用不是返回一个结果而是控制整个流程的走向。举一个比较完整的例子给用户加积分同时做参数校验和余额上限检查。DELIMITER //CREATE PROCEDURE add_points( IN p_user_id INT, IN p_points INT ) BEGIN DECLARE current_points INT DEFAULT 0; DECLARE user_exists INT DEFAULT 0;SELECT COUNT(*) INTO user_exists FROM users WHERE user_id p_user_id;IF user_exists 0 THEN SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT 用户不存在; END IF;IF p_points 0 THEN SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT 积分必须为正数; END IF;SELECT points INTO current_points FROM users WHERE user_id p_user_id FOR UPDATE;IF current_points p_points 999999 THEN SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT 积分超出上限; ELSE UPDATE users SET points current_points p_points WHERE user_id p_user_id; END IF;END//DELIMITER ;这里几个细节值得单独说。第一个是SIGNAL语句它用来主动抛异常。SQLSTATE 45000是通用的用户自定义错误码后面跟的MESSAGE_TEXT会被异常信息带出来。这个写法在存储过程的参数校验里是标配。第二个是SELECT ... FOR UPDATE。因为后面要基于当前积分做加法在高并发下必须先把目标行的锁拿住否则两个会话同时读到相同的老积分更新就会互相覆盖。这就是经典的并发控制问题。第三个是DELIMITER命令。MySQL的客户端会把分号当语句结束符如果不在创建存储过程之前换成别的分隔符你写的内部语句会被拆得七零八落。写完再换回来。这是我刚写存储过程犯过最多的一个重要细节。3.5 用CASE做行转列稍微高级一点的用法行转列报表。假设有一张学生成绩表每行是一个学生的一门课成绩现在要输出一行一个学生、三列分别是语文、数学、英语的成绩。SELECT student_name, MAX(CASE WHEN course_name 语文 THEN score END) AS chinese_score, MAX(CASE WHEN course_name 数学 THEN score END) AS math_score, MAX(CASE WHEN course_name 英语 THEN score END) AS english_score FROM student_scores GROUP BY student_name;这里CASE的作用是把行中的课程名转成列。注意我用MAX而不是SUM因为只要非NULL值就行学生这一科只有一条记录MAX就是那条分数。这个技巧做交叉表报表时非常常用原理也和IF异曲同工当course_name匹配时返回score不匹配时返回NULL然后聚合函数把NULL跳过去只留下匹配科目的分数。4. 常见问题与排查技巧实录4.1 WHEN条件的顺序陷阱搜索CASE最典型的bug是条件顺序放错。还是拿成绩分级举例SELECT score, CASE WHEN score 60 THEN 及格 WHEN score 85 THEN 优秀 ELSE 不及格 END AS grade FROM student_scores;这个SQL会导致85分以上的学生也显示“及格”因为第一条WHEN score 60已经命中了。正确的写法是把更精确的条件放前面CASE WHEN score 85 THEN 优秀 WHEN score 60 THEN 及格 ELSE 不及格 END所有WHEN条件是从上到下顺序匹配、命中即停止的这既是优点也是风险。以后写多层CASE时养成习惯条件范围越小、过滤越严的写前面范围大的写后面。4.2 NULL参与比较的诡异表现NULL在条件判断里非常容易踩坑。比如下面这段SELECT CASE WHEN score 90 THEN 优秀 WHEN score 90 THEN 一般 ELSE 缺考 END AS grade FROM student_scores;看起来逻辑闭环了——90优秀90一般其他走缺考。但score如果为NULL两个WHEN条件都不成立因为NULL和任何数字比较结果都是NULL而不是TRUE。结果就是成绩为NULL的学生被归入了“缺考”这个ELSE。你如果没写ELSE返回的就是NULL。所以处理可能存在NULL的字段时要么单独加WHEN score IS NULL THEN要么接受这种归入ELSE的行为但心里要有数。IF()函数也一样IF(score 90, 优秀, 一般)遇到NULL会直接走“一般”分支。这不是bug是SQL的三值逻辑在起作用——NULL与任何比较运算都产生未知。正确写法是IF(score 90, 优秀, IF(score IS NULL, 无成绩, 一般))。4.3 WHERE子句中使用条件判断导致索引失效WHERE里用IF或CASE完全可以写但通常是个性能陷阱。看这个查询SELECT * FROM orders WHERE IF(order_status 0, order_date, pay_date) 2025-01-01;逻辑上没问题但MySQL需要在每一行上先计算这个IF表达式才知道结果是否满足条件。正常情况下order_date和pay_date如果分别有索引这条SQL一个都用不上。数据量一大全表扫描的性能就很惨。改写方案是用布尔逻辑把条件拆开SELECT * FROM orders WHERE (order_status 0 AND order_date 2025-01-01) OR (order_status 0 AND pay_date 2025-01-01);这样两个分支可分别利用索引优化器有机会完成索引合并。我实测过百万行左右的数据量同样逻辑用IF写法查询耗时从200毫秒涨到1.8秒差距相当明显。条件判断放在SELECT字段上无所谓放在WHERE里要三思。4.4 IF()返回类型混用引发隐式转换IF()的第二、第三参数类型不一致时会有隐式转换。比如SELECT IF(1, 100, 100) AS result;MySQL会把整数100转成字符串100。反过来IF(0, 100, 100)也是字符串100。如果你用导出工具或者ETL对接下游很容易因为列类型是字符串而不是数值导致数据对接异常。比这个更隐蔽的是NULL参与SELECT IF(1, NULL, 100) AS result;MySQL会返回NULL值列下游程序接收时可能以为整列都是空。这类问题我在做数据清洗的时候踩过后来形成一条纪律IF()的两个返回值保持同类型要返回空值时用空字符串而不是NULL。这样避免隐式转换下游对接也省心。4.5 性能问题的定位思路用条件判断的SQL慢先别急着优化语法按顺序排查。第一步EXPLAIN看执行计划。如果条件字段在WHERE里导致全表扫描优先改写为普通条件。其次看possible_keys和key确认索引真正被用上。第二步检查CASE条件里有没有高延迟子查询。我曾经看到一个统计报表每个WHEN里都写了一个标量子查询比如CASE WHEN (SELECT COUNT(*) FROM ...) 0 THEN这种查询在每行都要执行一遍子查询不可能快。解决方法是先JOIN把统计结果算好再在外层CASE里引用已经计算好的字段。第三步判断是否做了无谓的计算。比如CASE里调用SUBSTR、正则函数把大字段拆分再比较。这种适合先在外面加工好字段或者换一种写法走前缀索引。我自己的经验是遇到慢SQL先把查询拆开跑逐个部分看耗时定位到具体是哪个表达式拖慢。不要一上来就加内存、加索引很多问题其实是SQL写法层面的。4.6 简单CASE不能做范围判断简单CASE只支持等值比较这个限制新手很容易犯错SELECT CASE order_amount WHEN 1000 THEN 大单 END FROM orders;这个直接语法报错因为简单CASE的WHEN后面只能写常量值或者可比较值不能写范围条件。遇到范围判断必须改成搜索CASECASE WHEN order_amount 1000 THEN 大单 END这个错误我记得自己犯过三次每次都是先写成简单CASE然后被报错提醒。写成搜索CASE时注意把CASE后面不写字段名直接以WHEN开头。5. 一点实操心法聊得差不多了分享几条我长期实践下来的经验准则。第一条能用CASE表达式就不用IF()函数。三个以上分支时IF()嵌套的阅读成本太高CASE的可读性和标准兼容性都是优势。只有那种二选一、条件很简单的场景比如IF(gender 1, 男, 女)IF()的简洁才是加分项。要形成这个条件反射写之前先数分支数量。第二条WHERE里尽量别放条件判断表达式。有大量过滤需求时用普通条件组合做索引友好型写法把CASE和IF限定在SELECT字段、ORDER BY、GROUP BY等可控位置。第三条存储过程里的IF语句要控制复杂度。一次存引擎能处理的流程不能太复杂。我遇到过一个几百行的存储过程中嵌套了十几层IF排故障的时候非常痛苦。后来统一约定存储过程里只做参数校验、简单状态流转、关键的读写操作再复杂的业务拆成多个存储过程或函数逐层调用。第四条学会用ELSE兜底。写CASE时不到万不得已不要省略ELSE。省略ELSE后未匹配行返回NULL这个NULL在聚合函数中会被忽略在报表中会显示空白定位问题时会增加很多干扰。默认给ELSE一个明确的值比如未知、0有利于数据完整性。另外提醒一点状态枚举比较多的字段与其在每条SQL里写CASE翻译不如直接建一张状态映射维表查询时JOIN一下。这是一种更数据库化的设计思路。表面上多了一条JOIN但维护性高很多改一个状态文案不用去改所有报表SQL。条件判断是工具不是所有问题的答案。说一千道一万MySQL里的条件判断其实就三样东西IF()函数解决快速二选一CASE表达式处理复杂多分支和字段加工存储过程中的IF语句做流程控制。把这三种形态分清楚、用对场景再配合今天提到的那些边界细节你写出来的SQL会明显比大多数人干净和稳定。动手找个真实业务表练练手多踩几个坑自然就记住了。