MySQL逻辑函数实战：IF、CASE WHEN、COALESCE用法与避坑指南

1. 逻辑函数到底解决什么问题：先想清楚SQL为什么需要“判断”

做MySQL开发的同学，写SQL写久了会有一个共同感觉：很多业务规则本质上就是“如果……就……否则……”。比如查询订单表，要根据订单状态显示不同文案；统计报表时，某个字段为空要显示默认值；计算优惠金额时，要判断满减条件是否满足。这些场景用Java、Python写很容易，无非是if-else，但问题在于：如果数据在数据库里，难道每次都要查出来到业务层再判断？

逻辑函数就是专门用来在SQL内部完成这种“判断”的一组函数。它最大的价值不是让SQL变短，而是让计算尽量靠近数据，减少应用层与数据库之间的往返，同时让数据查询本身具备表达能力。比如一张用户表里有手机号和邮箱，需求是“优先展示手机号，没有手机号就展示邮箱”，你可以在业务层取出来再写一堆if-else，也可以在SELECT语句里用一个IFNULL搞定，后者明显更干净。

这次想聊的逻辑函数，基本覆盖这几类：IF、IFNULL、NULLIF、CASE WHEN，以及和它们配合使用的COALESCE。很多人会问：CASE WHEN算函数吗？严格说它是表达式，但在实际使用中它做的工作就是逻辑函数的事，所以通常放在一起讲。此外还有逻辑运算相关的AND、OR、NOT，以及IN、LIKE、BETWEEN这类条件判断，它们和函数配合起来才能完成真正复杂的数据筛选。

这篇文章会把这几个函数的用法、区别、常见坑位都拆开讲清楚，并用实际业务场景串联起来。内容会涉及存储过程、触发器、UPDATE语句里的调用方式——因为不少人在这些场景里用逻辑函数踩过坑。无论是刚接触MySQL的读者，还是写了好几年SQL想补一补细节的开发者，应该都能找到有价值的内容。

在正式开始之前，先给一个总览表，后面每个函数都会展开：

有了这个框架，接下来逐个聊。

2. 四个核心函数逐个拆解：IF、IFNULL、NULLIF、COALESCE

2.1 IF函数：最基础的二分支判断

IF可能是最好理解的逻辑函数。它的语法很简单：IF(expr, value_if_true, value_if_false)。第一个参数是一个条件表达式，第二个参数是条件为真时返回的值，第三个参数是条件为假时返回的值。

举一个非常典型的例子。电商系统里有个订单表orders，里面有字段order_status，1代表已支付，2代表未支付，3代表已取消。现在要查所有订单，并显示一个可读的状态文案：

sql复制SELECT 
    order_id,
    order_amount,
    IF(order_status = 1, '已支付', '未完成') AS status_text
FROM orders;

这里IF做了分类映射。但要注意一个细节：IF的第二个和第三个参数可以是不同的数据类型，比如可以返回字符串，也可以返回数字。当两个返回值类型不一致时，MySQL会做隐式类型转换。我在实际工作中遇到过这样的问题：IF(condition, '是', 0)这个写法，返回的'是'和0会统一转成字符串，看起来没问题，但如果后续拿这个结果去做数值运算，就会出隐患。所以写IF时尽量保持两个返回值数据类型一致，或者做好CAST转换。

IF还有一个容易被忽略的用法：它可以嵌套。比如三个状态的分支，可以写成IF(condition1, 'a', IF(condition2, 'b', 'c'))。但这种写法可读性会迅速下降，如果分支超过三个，我更推荐用CASE WHEN，后面会详细说。

再来看一个统计场景。要统计一年内有过消费记录的客户占比，可以用IF配合聚合函数：

sql复制SELECT 
    SUM(IF(total_amount > 0, 1, 0)) AS active_customers,
    COUNT(*) AS total_customers,
    SUM(IF(total_amount > 0, 1, 0)) / COUNT(*) AS active_ratio
FROM customer_stats;

这段SQL的巧妙之处在于：IF在SUM内部充当了“条件计数”的作用。条件成立返回1，不成立返回0，SUM求和后就是满足条件的记录数。这比先查一个子集再COUNT要高效得多，因为只扫描了一次表。

2.2 IFNULL：补默认值的最顺手工具

IFNULL(v1, v2)的意思是：如果v1是NULL，返回v2；否则返回v1。它解决的几乎是日常开发中最常见的问题——NULL值处理。

回到文章开头提到的场景：用户表users中有phone和email两个字段，业务要求优先显示手机号，手机号为空时显示邮箱：

sql复制SELECT 
    user_id,
    IFNULL(phone, email) AS contact_info
FROM users;

一句话就搞定了。如果不用IFNULL，你大概率要写CASE WHEN phone IS NOT NULL THEN phone ELSE email END，又长又啰嗦。

IFNULL还有一个很实用的场景：计算百分比时防止NULL导致整个计算结果变成NULL。MySQL中任何数值和NULL进行算术运算，结果都会是NULL。比如计算折扣价：

sql复制SELECT 
    product_name,
    price,
    discount,
    price * IFNULL(discount, 1) AS final_price
FROM products;

如果discount字段允许为空，没有IFNULL兜底的话，只要discount是NULL，final_price就会变成NULL。这在实际报表里是个大坑，一个不经意就会让下游计算全盘出错。

但我必须提醒一点：IFNULL只能判断NULL，不能判断空字符串''。在很多业务系统里，空字符串和NULL的含义完全不同。如果接口传入了一个空字符串，IFNULL是拦不住的。此时需要的是NULLIF函数，下面会讲。

2.3 NULLIF：防止除零与数据对比的利器

NULLIF(v1, v2)的语义有些反直觉：如果v1等于v2，返回NULL；如果v1不等于v2，返回v1。它的价值主要体现在两个场景：一是防止除零，二是快速判断两个字段是否相同。

先看除零场景。报表统计中经常要计算“客单价”，即总收入除以订单数。如果订单数为0，直接相除会报错或被MySQL返回NULL（取决于SQL_MODE设置）。用NULLIF可以优雅地解决：

sql复制SELECT 
    seller_id,
    SUM(income) / NULLIF(COUNT(order_id), 0) AS avg_order_value
FROM orders
GROUP BY seller_id;

COUNT(order_id)为0时，NULLIF会把它变成NULL，那么整个除法结果就是NULL，而不会报错。拿到NULL之后，业务层可以再做处理，比如显示为0或“无数据”。这个写法比在应用层判断要高效得多。

再看字段比较场景。假设一张表同时记录了用户填写的身份证号和系统核验的身份证号，要找出填写不一致的记录：

sql复制SELECT 
    user_id,
    NULLIF(id_card_filled, id_card_verified) AS diff_value
FROM user_verify;

diff_value为NULL的行表示两个字段相同，非NULL则表示有差异。这种用法在做数据清洗、对账的时候特别好用。

不过NULLIF有一个需要注意的地方：它做的是“相等”判断，不涉及NULL本身。如果v1和v2都是NULL，NULLIF返回的也是NULL，因为NULL = NULL的结果是NULL（未知），所以条件不成立，返回v1也就是NULL。这个行为和预期刚好一致，但在代码评审时经常会被追问，理解原理后就能解释清楚。

2.4 COALESCE：多字段取值优先级的正确打开方式

COALESCE可以接受多个参数，返回从左到右第一个非NULL值。从功能上说，它是IFNULL的超级版本，因为IFNULL只有两个参数，而COALESCE可以写很多个。

典型的业务场景：客户联系方式可能有多个来源，比如手机号、邮箱、微信，需要按照优先级取第一个可用的：

sql复制SELECT 
    customer_id,
    COALESCE(phone, email, wechat, '无联系方式') AS contact
FROM customers;

COALESCE在这里依次判断phone、email、wechat，只要遇到非NULL就返回，如果全是NULL，则返回字符串'无联系方式'。

COALESCE和IFNULL还有一个细微差别：IFNULL只能传两个参数，COALESCE可以传多个。在性能上，二者几乎没差异，但COALESCE更灵活，而且它是标准SQL语法，迁移到其他数据库时兼容性更好。所以我的个人习惯是：两个字段的兜底用IFNULL，多个字段的取值优先级用COALESCE。

COALESCE还有一个容易踩的陷阱：它只判断NULL，不判断空字符串。如果你数据库里存的是''，COALESCE会认为这个值是有效的，直接返回空串。常见的处理方式是结合NULLIF一起用：

sql复制SELECT 
    customer_id,
    COALESCE(NULLIF(phone, ''), NULLIF(email, ''), '无联系方式') AS contact
FROM customers;

先用NULLIF把空字符串转换为NULL，COALESCE再取第一个非NULL值。这个组合拳在实际开发中非常常见，属于那种“文档里不会细讲但项目里必须会”的写法。

3. CASE WHEN：复杂分支逻辑的终极表达

3.1 为什么复杂判断首选CASE WHEN，而不是IF嵌套

IF函数用嵌套也能实现多分支，但嵌套层数一多，SQL几乎没法读。CASE WHEN就是为复杂分支设计的，它有两种写法。

第一种是简单CASE表达式，拿一个值跟多个值比较：

sql复制SELECT 
    order_id,
    CASE order_status
        WHEN 1 THEN '待支付'
        WHEN 2 THEN '已支付'
        WHEN 3 THEN '已发货'
        WHEN 4 THEN '已完成'
        ELSE '未知状态'
    END AS status_text
FROM orders;

这种写法要求CASE后的字段和WHEN后的值是相等比较，比较简单，适合“一个字段多个取值”的场景。

第二种是搜索CASE表达式，每个WHEN后面可以写任意布尔表达式：

sql复制SELECT 
    order_id,
    CASE 
        WHEN order_amount >= 1000 THEN '大额订单'
        WHEN order_amount >= 500 THEN '中等订单'
        ELSE '普通订单'
    END AS order_level
FROM orders;

这种写法更强大，因为WHEN后面可以写任意条件，甚至可以在别的WHEN里再用CASE做嵌套，可读性依然能保持。

简单CASE和搜索CASE的区别要搞清楚：简单CASE只能做等值判断；搜索CASE可以做各种逻辑组合。实际开发中搜索CASE用得更多，因为业务条件很少是纯粹的等值判断。

3.2 搜索CASE在统计报表中的高阶用法

CASE WHEN不仅能用来给查询结果做分类，还能在聚合函数内部做条件统计，这一能力在统计报表里堪称神器。

举一个典型的利润统计场景。有一张订单明细表order_items，字段包括order_id、category、amount、profit。现在要统计每个品类的总金额、总利润，以及“金额大于100的订单”的利润占比：

sql复制SELECT 
    category,
    SUM(amount) AS total_amount,
    SUM(profit) AS total_profit,
    SUM(CASE WHEN amount > 100 THEN profit ELSE 0 END) AS high_value_profit,
    SUM(CASE WHEN amount > 100 THEN profit ELSE 0 END) / NULLIF(SUM(profit), 0) AS high_value_ratio
FROM order_items
GROUP BY category;

这段SQL的核心在于SUM(CASE WHEN ... THEN ... ELSE 0 END)，它实现了“只把满足条件的记录参与求和，不满足的按0处理”。这种写法避免了多少次表扫描？答案是：原本可能需要四次查询（分别统计总金额、总利润、高价值利润、计算占比），现在一次扫描全搞定。在数据量大时，查询效率提升非常显著。

CASE WHEN在聚合里的另一个常见用法是行转列。假设有一张学生成绩表student_scores，字段包括student_id、subject、score，要把数学、语文、英语三科成绩转成一行显示：

sql复制SELECT 
    student_id,
    MAX(CASE WHEN subject = 'math' THEN score END) AS math_score,
    MAX(CASE WHEN subject = 'chinese' THEN score END) AS chinese_score,
    MAX(CASE WHEN subject = 'english' THEN score END) AS english_score
FROM student_scores
GROUP BY student_id;

这里的MAX只是一个聚合兜底，因为每个student_id + subject组合只有一条记录，MAX取到的就是那条记录的值；如果某个学生没有某科成绩，MAX返回NULL。这个技巧在报表开发中几乎是必备技能，掌握了它，很多“宽表”需求就不用再靠JOIN自连接硬凑了。

3.3 CASE WHEN的优先级与ELSE省略的坑

CASE WHEN是从上到下依次判断的，一旦某个WHEN条件满足，后面的WHEN就不再执行。这意味着条件的顺序很重要。很多人写多段区间判断时，习惯把大区间写前面，导致后面的分支永远走不到。比如：

sql复制CASE 
    WHEN amount >= 100 THEN 'A'
    WHEN amount >= 500 THEN 'B'  -- 永远执行不到，因为>=100已经包含了>=500
END

正确的写法应该从小到大排列分段，或者把更严格的条件写前面。稍不留神就会产出逻辑错乱的数据，而且这类错误不会报错，排查起来非常费劲。

另外，ELSE是可选的。如果不写ELSE，且所有WHEN条件都不满足，CASE表达式返回NULL。这个行为有时候符合预期，有时候是个坑。比如你想把不满足条件的记录标记为“其他”，结果没写ELSE，这些记录的值就变成NULL了，下游再做统计时很容易忽略这些数据。我的建议是：除非你明确知道“不满足条件时返回NULL是期望行为”，否则CASE WHEN必须写ELSE，哪怕ELSE 0或ELSE 'unknown'，避免数据出现“无声的空洞”。

4. 复合条件与隐式类型转换：逻辑函数配合AND/OR的隐藏陷阱

4.1 常见的热搜词“MySQL中int+5”到底是什么问题

写SQL时经常遇到字段类型和条件类型不匹配的情况。热搜词里有“mysql中int+5”，这个词看着奇怪，其实很多人在搜索：在SQL里给整型字段加数字，是不是直接+5就行了？为什么有时候结果是字符串拼接？

这个问题的根源是MySQL的隐式类型转换。当字符串和数字进行运算时，MySQL会尝试把字符串转换成数字。例如：

sql复制SELECT '5' + 5;

结果是10，因为字符串'5'被转换成了数字5。但如果是：

sql复制SELECT 'abc' + 5;

结果是5，因为'abc'无法转换为数字，MySQL把它当作0处理了（如果有SQL_MODE的严格模式，可能直接报错）。

这在逻辑判断里影响很大。比如查询时写：

sql复制SELECT * FROM users WHERE age + 5 > 30;

如果age字段是字符串类型，MySQL会先把age字符串转成数字再和5相加。如果age里有'18岁'这种格式，转换结果是18，也能得到预期效果；但如果有'unknown'这种非数字内容，转换结果就是0，逻辑完全错乱。所以在写带运算的条件时，一定要确保字段类型本身是数值型，不要依赖隐式转换，因为隐式转换的行为在不同MySQL版本和不同SQL_MODE下可能不一致。

4.2 热搜词“MySQL的or能去重吗”：逻辑运算符在使用中的典型误解

热搜词里还有一个很有意思的问题：“MySQL的or能去重吗”。这个问题的来源，大概是有人写了类似这样的SQL：

sql复制SELECT * FROM users WHERE name = '张三' OR name = '李四';

然后发现结果中出现了重复行，于是怀疑OR是不是不能去重。其实OR和去重之间没有任何关系。OR只是逻辑连接词，它决定了哪些行会被筛选出来。如果查询结果出现重复，唯一的原因是：结果集中存在完全重复的行，或者查询本身关联了多张表产生了笛卡尔积。

去重是DISTINCT或GROUP BY的职责。比如：

sql复制SELECT DISTINCT name FROM users WHERE name = '张三' OR name = '李四';

这才是正确的去重写法。所以下次如果遇到OR查询出现重复数据，先检查是不是表JOIN产生了重复行，或者SELECT的字段没包含唯一标识列，而不是去质疑OR本身。

OR在逻辑函数场景中还有一个常被忽略的性能问题：OR连接的多个条件可能导致索引失效。MySQL优化器对OR的优化相对有限，如果条件中的列有索引，但用OR连接后，索引扫描很多时候会退化为全表扫描。举个例子：WHERE user_id = 1 OR user_name = 'admin'，即使user_id和user_name上都有索引，MySQL也可能无法同时使用两个索引合并结果。更稳妥的方案是用UNION改写：

sql复制SELECT * FROM users WHERE user_id = 1
UNION
SELECT * FROM users WHERE user_name = 'admin';

每个分支都可以单独走索引。当然，具体是否要改写还是要看EXPLAIN的输出。这个知识点虽然不是逻辑函数本身，但和AND/OR组合在一起理解，才能写出又正确又高效的SQL。

4.3 IN、LIKE、BETWEEN与逻辑判断的边界条件

IN可以看作“多个OR”的简写形式，语义是“集合中任意一个值匹配即可”：

sql复制SELECT * FROM users WHERE status IN ('active', 'pending', 'trial');

这里有个小坑：IN列表中的NULL。如果写成status IN ('active', NULL)，MySQL对NULL的比较结果是NULL，也就是“未知”，而不是TRUE。因此，status为NULL的行不会被这个条件选中。如果你希望把字段为NULL的行也查出来，需要显式加OR status IS NULL。

LIKE在做模糊匹配时，本质上也是逻辑判断。最容易被忽略的是大小写问题。LIKE在MySQL中的大小写规则，取决于字段的排序规则（collation）。如果字段用的是utf8mb4_general_ci（ci即case insensitive），那么LIKE 'a%'会匹配'Apple'；如果用的是utf8mb4_bin，则不会。这个细节经常导致“开发环境正常，生产环境查不到数据”的问题。配合逻辑函数使用时，可以先通过COLLATE明确指定排序规则，或者用LOWER、UPPER函数统一大小写，保证结果可预期。

BETWEEN是范围判断，等价于>= AND <=，它是闭区间。很多人写BETWEEN时没有注意到这个细节。比如BETWEEN 10 AND 20会同时包含10和20。如果你希望的是“大于等于10且小于20”，用BETWEEN就多包含了20，必须写成BETWEEN 10 AND 19，或者干脆用显式的>=和<。这种边界问题在分页和统计场景中经常造成误差，量小的时候不容易发现，量大会直接影响报表数据。

5. 在UPDATE、存储过程、触发器中活用逻辑函数

5.1 UPDATE语句中根据条件更新不同字段

逻辑函数在UPDATE中同样能发挥大作用。一个经典场景：根据条件更新不同字段的值。比如用户表里记录用户的会员等级和积分，需求是“当积分超过1000时，把会员等级改为VIP，否则把积分清零并保留普通等级”：

sql复制UPDATE users
SET 
    level = IF(points > 1000, 'VIP', 'normal'),
    points = IF(points > 1000, points, 0)
WHERE user_id = 123;

这样一条UPDATE，就把原本需要多条UPDATE或业务层事务处理的逻辑全部收敛到了SQL里。而且在同一行内先读取points再更新points，是执行当前行的更新，语义上是安全的。

还可以结合CASE WHEN做更复杂的更新。比如订单表中，根据订单创建时间批量修改配送优先级：

sql复制UPDATE orders
SET delivery_priority = CASE
    WHEN created_at >= NOW() - INTERVAL 1 DAY THEN 'high'
    WHEN created_at >= NOW() - INTERVAL 3 DAY THEN 'medium'
    ELSE 'low'
END
WHERE order_status = 'pending';

这类批量更新在运营后台特别常用。但要注意，UPDATE中使用函数会让索引失效的风险增加。如果这列本身有索引，且UPDATE的WHERE条件依赖该列上的函数计算结果，优化器可能无法走索引。所以大批量更新时，建议先用SELECT确认影响行数和执行计划，再执行UPDATE。

5.2 存储过程中的IF分支：注意与SQL函数如果混用的结果

MySQL存储过程支持IF-THEN-ELSE语法，它的写法与SQL函数IF有相似之处，但完全是两回事。例如：

sql复制DELIMITER $$

CREATE PROCEDURE sp_update_user_status(IN p_user_id INT)
BEGIN
    DECLARE v_points INT;
    
    SELECT points INTO v_points FROM users WHERE user_id = p_user_id;
    
    IF v_points > 1000 THEN
        UPDATE users SET level = 'VIP' WHERE user_id = p_user_id;
    ELSE
        UPDATE users SET level = 'normal' WHERE user_id = p_user_id;
    END IF;
END$$

DELIMITER ;

这里的IF是存储过程的流程控制语句，不是函数。很多人第一次接触时容易混淆，导致语法错误。

存储过程中还常见一个坑：局部变量的值如果为NULL，IF判断会出问题。比如v_points是NULL，那么IF v_points > 1000的结果是NULL，不是TRUE也不是FALSE。在存储过程中，NULL在IF条件下会被当作FALSE处理，所以会走到ELSE分支。这个行为跟预期可能不一样。因此，在存储过程中用IF做判断前，最好先用IFNULL把变量兜底：

sql复制IF IFNULL(v_points, 0) > 1000 THEN

这个细节很实用，我在写存储过程时至少踩过两三次这种坑，排查半天发现是NULL值把判断逻辑带偏了。

另一个经常出现的问题是事务和IF的配合。在存储过程里做条件更新，要记得把BEGIN和COMMIT放在外层。很多人写完存储过程后发现一部分更新成功、一部分没成功，就是因为没加事务控制。逻辑分支本身没问题，但数据完整性出问题，最后还是得靠事务兜住。

5.3 触发器中的NEW/OLD判断：用逻辑函数保护数据

触发器中经常要用NEW和OLD关键字来引用新数据和旧数据，逻辑函数在这里最常见的用途是校验和自动填充。

比如设计一个订单表，希望在插入记录时，如果未指定优惠金额，则自动填0：

sql复制DELIMITER $$

CREATE TRIGGER trg_orders_before_insert
BEFORE INSERT ON orders
FOR EACH ROW
BEGIN
    SET NEW.discount_amount = IFNULL(NEW.discount_amount, 0);
END$$

DELIMITER ;

再比如更新用户余额时，禁止余额被更新为负数：

sql复制DELIMITER $$

CREATE TRIGGER trg_account_before_update
BEFORE UPDATE ON accounts
FOR EACH ROW
BEGIN
    IF NEW.balance < 0 THEN
        SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'balance cannot be negative';
    END IF;
END$$

DELIMITER ;

这里用IF做条件判断，加上SIGNAL主动抛错，能在数据源头阻止非法数据进入表。这个做法比在应用层校验更可靠，因为所有写入路径都会被拦截。当然，触发器本身也有性能开销，高并发写入场景下不建议堆太多逻辑，这点要权衡。

另外要提醒一个和DELIMITER相关的问题。热搜词里有“mysql中触发器中分隔符”，其实就是因为触发器内部包含分号，而默认的SQL语句结束符也是分号，导致客户端无法正确区分整个触发器的结束位置。所以创建触发器时必须先把结束符改成其他符号，比如DELIMITER $$，创建完成后再改回DELIMITER ;。这个操作不影响触发器内部逻辑，但很多人没意识到这个先决条件，直接写语句就报语法错误。

5.4 逻辑函数在JOIN查询中的“皮一下”用法

还有一类场景值得聊聊，就是JOIN中的逻辑函数。很多时候，关联查询需要根据条件来决定关联哪张表。

假设订单表orders中有一个字段source_type，1表示来自线上商城，2表示来自门店。线上商城的订单关联online_order_info表获取配送信息，门店订单关联store_order_info表获取门店信息。可以用CASE WHEN组装关联：

sql复制SELECT 
    o.order_id,
    o.amount,
    CASE 
        WHEN o.source_type = 1 THEN oi.tracking_no
        WHEN o.source_type = 2 THEN si.store_address
    END AS logistics_info
FROM orders o
LEFT JOIN online_order_info oi ON o.order_id = oi.order_id AND o.source_type = 1
LEFT JOIN store_order_info si ON o.order_id = si.order_id AND o.source_type = 2
WHERE o.order_id = 456;

这种方式通过逻辑条件控制JOIN的匹配条件，避免了一次性关联两张表带来的数据膨胀。不过要注意，这种做法对索引要求较高，JOIN条件中的逻辑判断会影响优化器选择。实际生产中如果数据量不小，我更建议把数据拆成两个查询然后在业务层合并，或者使用UNION ALL分别查询再拼结果，这样更容易控制执行计划。逻辑函数不是万能的，该拆查询时还是得拆。

6. 容易翻车的边界场景：NULL三值逻辑、大小写规则与索引失效

6.1 NULL三值逻辑：为什么“=NULL”查不到东西

逻辑判断中有一个基本认知：SQL使用的是三值逻辑，即TRUE、FALSE和UNKNOWN。NULL参与任何比较运算，结果通常都是UNKNOWN，而不是TRUE或FALSE。所以WHERE name = NULL永远查不到数据，必须写成WHERE name IS NULL。

这个三值逻辑对逻辑函数的影响非常大。比如：

sql复制SELECT IF(NULL = NULL, '相等', '不相等');

结果是什么？“不相等”。因为NULL = NULL的结果是UNKNOWN，IF在UNKNOWN情况下走的是else分支。虽然直觉上NULL等于NULL好像“应该相等”，但SQL语义不是这么定义的。这导致很多刚学SQL的人栽跟头。

在CASE WHEN里也一样，WHEN NULL = NULL做条件，永远是假的。所以判断NULL一定要用IS NULL，不能用=。而IFNULL和COALESCE本质上是“检测NULL并替换”，它们操作的是NULL值的特殊规则，不受等值比较限制。

6.2 大小写与排序规则：为什么有时候查不到“Apple”

热搜词里还有一个“mysql自动忽略大小写？”，这个问题和排序规则直接相关。MySQL中字符串比较是否区分大小写，由排序规则决定。utf8mb4_general_ci和utf8mb4_unicode_ci这样的后缀为_ci的排序规则是大小写不敏感的，而以_bin结尾或cs后缀的排序规则是大小写敏感的。

举例来说，在utf8mb4_general_ci排序规则下：

sql复制SELECT * FROM products WHERE name = 'apple';

能查出name为'Apple'或'APPLE'的记录。但如果表字段用的是utf8mb4_bin排序规则，同样的查询就查不出来。

这个特性会直接影响逻辑函数的判断结果。比如IF(name = 'apple', 1, 0)，在大小写不敏感排序规则下，name为'Apple'也会返回1；在大小写敏感排序规则下则返回0。这种差异在开发环境往往不显现，因为默认建表可能用了大小写不敏感的排序规则，但生产环境如果专门配置过排序规则，行为就可能完全不同。

一个稳妥的解法是显式指定比较方式：

sql复制SELECT * FROM products WHERE BINARY name = 'apple';

或者使用LOWER函数统一转小写再比较：

sql复制SELECT * FROM products WHERE LOWER(name) = LOWER('apple');

但要注意，在索引列上使用LOWER函数会导致索引失效。所以如果比较频繁且大小写敏感是硬需求，建议在建表时就选对排序规则，而不是在查询时靠函数弥补。

6.3 函数包裹索引列：索引为什么会失效

逻辑函数在SELECT和WHERE中使用时，最大的性能隐患是导致索引失效。比如有一个联合索引idx_created_at，查询写法：

sql复制SELECT * FROM orders WHERE DATE(created_at) = '2025-01-01';

这里对created_at用了DATE函数，MySQL无法直接利用idx_created_at进行范围查找，可能退化为全表扫描。正确写法是：

sql复制SELECT * FROM orders WHERE created_at >= '2025-01-01 00:00:00' AND created_at < '2025-01-02 00:00:00';

后者是纯范围条件，索引可以正常使用。

同理：

sql复制SELECT * FROM users WHERE YEAR(birthday) = 1990;

改成范围写法：

sql复制SELECT * FROM users WHERE birthday >= '1990-01-01' AND birthday < '1991-01-01';

函数本身不是罪过，但在索引列上套函数就是让优化器“难堪”。这在SQL优化的讨论里是老生常谈，但每次项目里还是会有人踩，尤其是刚接触逻辑函数的人，喜欢在WHERE里用IF、CASE，写完发现数据量一大查询就慢得离谱。

6.4 空字符串与NULL：看似一样，逻辑上截然不同

前面反复提到空字符串和NULL的差异，这里单独说清楚。NULL表示“没有值”，空字符串表示“有值，但值是空文本”。逻辑函数对二者的处理方式各不相同：

• IFNULL只处理NULL，不处理''；
• NULLIF可以先把''转换为NULL，再配合COALESCE使用；
• 在CASE WHEN中，判断''要用= ''，判断NULL要用IS NULL，两者不能混用；
• 在ORDER BY中，NULL和''的排序位置也不同：默认升序时，NULL排在最前面，''排在NULL后面。

一个典型的业务坑：用户在填写联系方式时，前端可能传了一个空字符串而不是不传字段。数据库里存的phone是''，而不是NULL。查询时用COALESCE(phone, email)会发现返回的居然是''，因为COALESCE认为''不是NULL，是有效值。这个问题我曾经在一个客户数据报表里排查了很久，最后才发现是空字符串惹的祸。解决方案就是前面提到的组合：

sql复制COALESCE(NULLIF(phone, ''), email)

这个组合把空字符串和NULL统一处理了。如果业务里既有NULL又有''，建议在写入时做一次规范化，让数据层保持一种“空”的语义，而不是到查询时每次都做各种转换。

6.5 逻辑函数与GROUP BY、DISTINCT的协作：去重和分组时的意外行为

用GROUP BY分组时，如果SELECT中出现了逻辑函数，要注意这些函数是在分组之后才计算的，还是分组之前就计算的。MySQL的执行顺序是：FROM > WHERE > GROUP BY > HAVING > SELECT > DISTINCT > ORDER BY > LIMIT。所以SELECT中的逻辑函数是在GROUP BY完成之后计算的，它只能看到每个分组的结果，而不是每一行原始数据。

举个例子：

sql复制SELECT 
    user_id,
    IF(SUM(amount) > 1000, '高消费', '普通') AS level
FROM orders
GROUP BY user_id;

这里IF拿到的是SUM(amount)的结果，也就是分组后的聚合值，逻辑函数作用于聚合结果。如果你的本意是“判断每笔订单金额再分组”，那就得先在WHERE中过滤，或者在聚合函数内部写CASE WHEN，而不是在SELECT层写IF。

DISTINCT和逻辑函数组合时也要注意。DISTINCT是对最终结果去重，如果SELECT中包含了IF/COALESCE等逻辑处理后的字段，DISTINCT会基于处理后的值去重，而不是原始值。比如：

sql复制SELECT DISTINCT IF(status = 1, 'active', 'inactive') FROM orders;

这里DISTINCT去重的是'active'和'inactive'这两个处理后的值，而不是原始的status。如果你还怀疑“OR能不能去重”这类问题，多半是混淆了筛选条件和去重机制。筛选决定哪些行进入结果集，去重决定结果集中保留哪些行，它们是两个阶段的事。

7. 我的实测心得与避坑建议

逻辑函数系列虽然看起来基础，但我在实际项目中见过太多因为使用不当导致的问题。简单做个总结和补充。

第一，能用COALESCE就别写多层IF。IF嵌套超过两层，代码可读性就断崖式下降。改成COALESCE或CASE WHEN后，逻辑一目了然，后续维护的人也不用对着三层IF猜你的原意。

第二，凡是可能为NULL的字段，参与运算前先想清楚要不要兜底。数值运算遇到NULL会变成NULL，字符串连接遇到NULL也可能产生意外结果。很多报表数据异常都是从一个未处理的NULL开始的。

第三，逻辑函数不背性能锅，但包裹索引列会让优化器束手无策。能用范围条件就用范围条件，函数尽量放在常量一侧或SELECT列表，而不是WHERE的字段一侧。

第四，CASE WHEN里的WHEN顺序就是执行顺序，条件写反了不会报错，只会出错误数据。每次写完多条件判断，我都会把边界值代入一遍验证，比如最小、最大、恰好相等、NULL这几种情况，确认分支没有错位。

第五，注意字符集和排序规则对字符串比较的影响。MySQL默认的utf8mb4_general_ci大小写不敏感，这在你做用户登录校验、去重统计时会带来“意想不到的宽松”。如果业务需要严格区分大小写，要么改字段排序规则，要么用BINARY关键字显式指定。

第六，逻辑函数在存储过程和触发器中使用时，先确认变量的值是否为NULL。很多诡异的存储过程行为，最后排查下来都是IF判断NULL值走错了分支。

最后再分享一个我自己习惯用的工具性查询。开发时想快速看某一个逻辑函数的返回结果，不用建表，直接SELECT：

sql复制SELECT 
    IF(1 > 0, 'true', 'false'),
    IFNULL(NULL, 'default'),
    NULLIF(5, 5),
    COALESCE(NULL, NULLIF('', ''), 'first_non_null');

这个查询能直观看到各个函数的基本行为和边界结果，排查问题时特别方便，比翻文档快得多。逻辑函数本身不难，难的是把它放在正确的场景、用正确的方式和边界规则配合起来。把这几个函数用熟了，你会发现SQL的表达力比想象中强很多。