企业官网建设流程全解析

1. 为什么你写的CASE WHEN总被同事质疑“逻辑绕”？——从真实SQL评审现场说起

上周帮团队做SQL代码走查，看到一段处理学生成绩等级的逻辑：

SELECT name, score, CASE WHEN score >= 90 THEN 'A' WHEN score >= 80 THEN 'B' WHEN score >= 70 THEN 'C' WHEN score >= 60 THEN 'D' ELSE 'F' END AS grade FROM students;

看起来很标准，对吧？但评审时资深DBA直接问：“如果score是NULL，这条记录会进ELSE分支吗？”
我下意识答“会”，他摇摇头：“错。CASE WHEN的WHEN子句里，score >= 90这种比较运算，当score为NULL时，整个表达式结果是UNKNOWN，不是TRUE也不是FALSE——所以它不会匹配任何WHEN分支，最终落到ELSE。”
全场安静了三秒。

这就是条件判断函数最常被忽略的底层真相：SQL的三值逻辑（TRUE/FALSE/UNKNOWN）不是编程语言的二值逻辑（true/false）。你写的每一个IF、每一个COALESCE、每一个嵌套CASE，背后都运行着这套与直觉相悖的规则。而市面上90%的MySQL教程，只教“怎么写”，不教“为什么这样写才安全”。

这篇指南不讲语法定义，不列函数手册——我们直接钻进生产环境的真实场景：成绩分级、订单状态映射、空值兜底、多条件优先级冲突、性能陷阱……用你每天都在写的SQL语句，拆解每个函数的执行边界、隐含假设和踩坑瞬间。关键词就五个：MySQL、IF、CASE WHEN、COALESCE、条件判断函数——但它们背后，是一整套影响查询结果正确性、数据一致性甚至业务资金结算的底层机制。

适合谁读？如果你写过WHERE条件但不确定NULL值怎么走分支；如果你用过IF函数却在报表里发现“空数据没显示”；如果你复制过网上的CASE WHEN模板却在联表查询时结果错乱——这篇文章就是为你写的。它不假设你懂事务隔离级别，也不要求你会写存储过程，只要你会写SELECT * FROM table WHERE id = 1，就能看懂每一处细节背后的“为什么”。

2. IF函数：看似简单，实则藏着三重陷阱的“快捷键”

IF函数是MySQL里最像编程语言三元运算符的语法：IF(条件, 真值, 假值)。初学者爱用它，因为写起来快——比如把性别码转成中文：

SELECT name, IF(sex = 1, '男', '女') AS gender FROM users;

干净利落。但当你把这张表交给财务部门做工资单时，问题来了：如果sex字段允许NULL，这个IF返回什么？

2.1 陷阱一：NULL参与比较时的“静默失效”

执行这条SQL：

SELECT IF(NULL = 1, '男', '女') AS result;

结果是'女'。

表面看合理——条件不成立，走假值分支。但底层逻辑是：NULL = 1的结果不是FALSE，而是UNKNOWN。而IF函数对UNKNOWN的处理规则是：当条件表达式求值为UNKNOWN时，IF函数将其视为FALSE。

这和CASE WHEN完全不同。CASE WHEN遇到UNKNOWN会跳过当前WHEN，继续匹配下一个；IF函数则直接判定为FALSE。这个差异在业务中可能引发严重误判。例如用户注册时未填性别，数据库存为NULL，你的IF函数把它当成“女”，而实际业务规则是“未填性别需人工复核”——系统却自动打上了标签。

提示：IF函数的条件分支只有两个出口（TRUE/FALSE），它没有“第三种状态”的处理能力。一旦涉及NULL，就必须显式判断。

2.2 陷阱二：嵌套IF的可读性灾难与维护风险

当业务规则变复杂，比如根据年龄分段打标签：

• 0-12岁：儿童
• 13-18岁：青少年
• 19-65岁：成年人
• 66岁以上：老年人
• NULL或负数：异常

有人会这么写：

SELECT name, age, IF(age IS NULL OR age < 0, '异常', IF(age <= 12, '儿童', IF(age <= 18, '青少年', IF(age <= 65, '成年人', '老年人') ) ) ) AS age_group FROM users;

这段代码能跑通，但三个月后你再看，需要逐层缩进数括号才能理清逻辑。更致命的是：当新增“退休人员（60-65岁）”子类时，你得在第四层IF里插入新分支，极易漏掉某个ELSE或写错边界。我在上一家公司就遇到过类似案例——市场部要求把“60-65岁”单独标记为“准退休”，开发改完上线，结果所有65岁以上用户都被标成了“准退休”，因为修改时少写了一个<=。

2.3 陷阱三：类型隐式转换引发的数据截断

IF函数要求真值和假值必须能隐式转换为同一类型，否则MySQL会强制转换并可能丢失精度。看这个例子：

SELECT IF(1 > 0, 3.1415926, '3.14') AS pi_value;

结果是什么？不是3.1415926，也不是字符串'3.14'，而是3.1415926000000003——一个双精度浮点数。因为MySQL发现真值是DECIMAL，假值是字符串，于是把字符串'3.14'转成浮点数再和真值对齐，导致精度污染。

更危险的是字符集转换：

SELECT IF(id = 1, '张三', 'John') AS name FROM users;

如果表字符集是utf8mb4，而'John'是ASCII编码，MySQL会把'张三'转成latin1再拼接——轻则乱码，重则报错Illegal mix of collations。我在电商大促期间处理过一次库存同步失败，根因就是日志表里用IF拼接中英文状态，字符集不一致导致INSERT中断。

2.4 实战建议：什么场景该用IF？什么场景必须换CASE？

我现在的硬性规范：所有涉及业务状态映射、空值兜底、多条件判断的SQL，一律禁用IF，改用搜索式CASE WHEN。不是因为它慢——单条IF比CASE快0.02ms，而是因为它把逻辑风险藏得太深。就像开车不系安全带，短途没事，长途出事就是大事。

3. CASE WHEN：你以为的“万能开关”，其实是精密仪器的操作面板

CASE WHEN常被称作SQL里的“瑞士军刀”，但很少有人意识到：它其实有两种完全不同的工作模式——简单CASE和搜索CASE。它们的语法相似，语义却天差地别，用错一种，结果可能全错。

3.1 简单CASE：等值匹配的“快捷通道”，但仅限精确相等

语法结构：

CASE 表达式 WHEN 值1 THEN 结果1 WHEN 值2 THEN 结果2 ... ELSE 默认结果 END

典型用法：把订单状态码转成中文名。

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

这里status是TINYINT类型，值域明确（0-3）。简单CASE的优势在于：它先计算status一次，然后用哈希查找匹配WHEN值，时间复杂度O(1)。比搜索CASE的逐条判断快得多。

但它的致命限制是：WHEN后面只能是常量或字面值，不能是表达式。下面这段代码会报错：

-- ❌ 错误！简单CASE不支持表达式 CASE score WHEN score >= 90 THEN 'A' -- 语法错误 ... END

更隐蔽的坑是类型隐式转换。假设status字段是VARCHAR('0')，而你在WHEN里写WHEN 0（数字0）：

CASE status WHEN 0 THEN '待支付' -- MySQL会把字符串'0'转成数字0再比较 WHEN 1 THEN '已支付' END

这看似没问题，但如果status存的是'00'（带前导零），'00' = 0的结果是TRUE（因为字符串转数字时忽略前导零），导致本该是“未知状态”的记录被误标为“待支付”。我在银行对账系统里见过真实案例：交易码'001'和'1'被当成同一状态，造成千万级资金差错。

3.2 搜索CASE：真正的逻辑引擎，但性能需精调

语法结构：

CASE WHEN 条件1 THEN 结果1 WHEN 条件2 THEN 结果2 ... ELSE 默认结果 END

这才是处理复杂业务逻辑的主力。回到成绩分级的例子：

SELECT name, score, CASE WHEN score IS NULL THEN '缺考' WHEN score < 0 OR score > 100 THEN '异常分数' WHEN score >= 90 THEN 'A' WHEN score >= 80 THEN 'B' WHEN score >= 70 THEN 'C' WHEN score >= 60 THEN 'D' ELSE 'F' END AS grade FROM students;

注意这里的顺序：NULL判断必须放在最前面。因为score >= 90遇到NULL会返回UNKNOWN，跳过该分支；但如果把ELSE 'F'放在NULL判断之前，NULL就会被错误归入ELSE。这是新手最常犯的错误——把“兜底逻辑”写在前面，结果所有空值都被粗暴打标。

搜索CASE的执行逻辑是从上到下顺序扫描，遇到第一个为TRUE的WHEN即返回结果，不再检查后续分支。这意味着：

• 条件顺序 = 业务优先级。比如订单状态中，“已取消”应优先于“已支付”，因为取消的订单不能再发货；
• 范围条件必须从大到小排列。score >= 90必须在score >= 80之前，否则95分永远匹配不到A级；
• 避免条件重叠。score > 80和score >= 80同时存在，会导致80分匹配到前者，逻辑混乱。

3.3 性能真相：CASE WHEN真的慢吗？关键在索引与谓词下推

很多人说“CASE WHEN影响性能”，其实是个误解。真正拖慢查询的是CASE表达式出现在WHERE子句中导致索引失效。看这个反模式：

-- ❌ 千万别这么写！ SELECT * FROM orders WHERE CASE status WHEN 0 THEN 'pending' WHEN 1 THEN 'paid' END = 'paid';

这里CASE被用在WHERE里，MySQL无法将'paid'反向映射到status=1，只能全表扫描。正确写法是：

-- ✅ 直接用原始字段 SELECT * FROM orders WHERE status = 1;

但如果CASE必须在WHERE中（比如多状态合并查询），可以用谓词下推技巧：

-- ✅ 先过滤再计算 SELECT order_id, CASE status WHEN 0 THEN '待支付' WHEN 1 THEN '已支付' END AS status_text FROM orders WHERE status IN (0, 1); -- 让索引生效

另一个性能杀手是在JOIN条件中滥用CASE：

-- ❌ 危险！关联字段被CASE包裹 SELECT u.name, o.total FROM users u JOIN orders o ON u.id = CASE WHEN o.user_type = 'vip' THEN o.vip_user_id ELSE o.normal_user_id END;

这会让MySQL放弃使用u.id索引，改为嵌套循环连接。解决方案是拆成UNION ALL：

-- ✅ 分离逻辑，保留索引 SELECT u.name, o.total FROM users u JOIN orders o ON u.id = o.vip_user_id AND o.user_type = 'vip' UNION ALL SELECT u.name, o.total FROM users u JOIN orders o ON u.id = o.normal_user_id AND o.user_type != 'vip';

3.4 高阶技巧：用CASE WHEN实现动态排序与条件聚合

CASE WHEN的威力远不止状态转换。它能让SQL具备“程序化”能力。

动态排序（按不同字段排序）：

SELECT * FROM products ORDER BY CASE WHEN @sort_by = 'price' THEN price WHEN @sort_by = 'sales' THEN sales_volume ELSE create_time END DESC;

注意：这里@sort_by是用户传入的变量，MySQL会为每个分支生成独立的排序路径，实际执行时只走一条。

条件聚合（同一查询中统计不同维度）：

SELECT COUNT(*) AS total_orders, COUNT(CASE WHEN status = 1 THEN 1 END) AS paid_count, COUNT(CASE WHEN status = 2 THEN 1 END) AS shipped_count, AVG(CASE WHEN status = 3 THEN amount END) AS avg_completed_amount FROM orders;

这里COUNT(CASE WHEN...)利用了COUNT忽略NULL的特性——只有满足条件时返回1，否则返回NULL，COUNT只计数非NULL值。比用多个子查询快3倍以上，且避免了笛卡尔积风险。

4. COALESCE：空值处理的“安全气囊”，但别把它当万能胶

COALESCE是最常被误用的函数之一。它的签名很简单：COALESCE(value1, value2, ..., valueN)，返回第一个非NULL的值。初学者觉得它“比IF好写”，但它的设计哲学和IF、CASE有本质区别——COALESCE是空值传播的终结者，不是条件判断器。

4.1 核心原则：COALESCE只解决“空值替代”，不解决“逻辑分支”

看这个典型错误：

-- ❌ 用COALESCE替代CASE SELECT name, COALESCE(phone, email, '暂无联系方式') AS contact FROM users;

这段代码的意图是：有手机号用手机号，没有就用邮箱，都没有就写“暂无”。但它隐藏着一个业务漏洞：如果phone是空字符串''（不是NULL），COALESCE会直接返回''，而不是继续检查email。因为空字符串是有效值，不是NULL。

而实际业务中，“手机号为空字符串”和“手机号为NULL”往往代表不同含义：

• NULL：用户未填写，需引导补全
• ''：用户填了但提交时被清空，可能是前端校验漏洞

用COALESCE一把抓，就把两种情况混为一谈。正确做法是显式区分：

-- ✅ 显式处理空字符串和NULL SELECT name, CASE WHEN phone IS NOT NULL AND phone != '' THEN phone WHEN email IS NOT NULL AND email != '' THEN email ELSE '暂无联系方式' END AS contact FROM users;

4.2 类型陷阱：COALESCE强制统一类型，可能引发静默截断

COALESCE要求所有参数必须能转换为同一数据类型，MySQL会选择“最宽泛”的类型作为结果类型。看这个例子：

SELECT COALESCE(100, 'abc', 3.14) AS result;

结果是'100'（字符串），因为字符串类型优先级高于数字。但如果你期望返回数字，就会出错。

更危险的是日期类型：

SELECT COALESCE('2023-01-01', NOW()) AS date_val;

结果是'2023-01-01'（字符串），而NOW()返回DATETIME。如果后续用这个结果做日期计算（如DATE_ADD(date_val, INTERVAL 1 DAY)），会触发隐式转换，性能暴跌且结果不可靠。

我的经验：只要COALESCE参数包含字符串，结果一定是字符串；只要包含日期，结果一定是日期类型。务必在调用前确认类型一致性。

4.3 替代方案对比：COALESCE vs IFNULL vs NVL（MySQL特有）

MySQL提供了三个空值处理函数，适用场景截然不同：

特别注意NULLIF：它是COALESCE的镜像操作，常用于清洗数据。比如订单表里，cancel_reason字段如果等于'N/A'，应视同NULL：

SELECT order_id, NULLIF(cancel_reason, 'N/A') AS clean_reason FROM orders;

4.4 生产级实践：用COALESCE构建“防御性SQL”

在金融系统中，我坚持用COALESCE做三层防护：

SELECT -- 第一层：字段级兜底（防止NULL） COALESCE(amount, 0) AS amount, -- 第二层：计算级兜底（防止除零） COALESCE( CASE WHEN total_quantity > 0 THEN amount / total_quantity ELSE NULL END, 0 ) AS unit_price, -- 第三层：关联级兜底（防止外键缺失） COALESCE( (SELECT name FROM products WHERE id = o.product_id), '未知商品' ) AS product_name FROM orders o;

这里的关键是：COALESCE只负责“保底”，不负责“决策”。真正的业务逻辑（如“金额为0是否合法”“除零是否应报错”）必须在应用层校验，SQL只做最后的安全屏障。这符合“数据库只管数据，业务逻辑在服务层”的架构原则。

5. 终极避坑清单：12个让DBA连夜删库的真实案例

这些不是理论假设，而是我过去五年在三家公司的血泪教训。每一条都对应一次线上事故，附带修复方案和验证方法。

5.1 CASE WHEN的“ELSE黑洞”：漏写ELSE导致数据消失

事故：报表系统显示某类订单数量为0，但业务方确认当天有100+单。排查发现，CASE WHEN分支覆盖不全：

CASE status WHEN 0 THEN 'pending' WHEN 1 THEN 'paid' WHEN 2 THEN 'shipped' END -- ❌ 没有ELSE！

status=3（已完成）的记录，CASE返回NULL，被WHERE或GROUP BY过滤掉。

修复：强制所有CASE WHEN带ELSE，并用/* TODO: review this default */标注待确认：

CASE status WHEN 0 THEN 'pending' WHEN 1 THEN 'paid' WHEN 2 THEN 'shipped' ELSE 'unknown_status' -- TODO: review this default END

验证：执行SELECT DISTINCT status FROM orders，确保所有值都在WHEN分支中。

5.2 IF函数的“NULL盲区”：用户注册信息错乱

事故：新用户注册时，未填邮箱的用户在后台显示邮箱为''（空字符串），但CRM系统认为''是有效邮箱，触发了无效邮件发送。

根因：注册SQL用了IF(email = '', 'no_email@domain.com', email)，但数据库email字段默认值是NULL，不是''。

修复：统一用COALESCE处理空值，再用CASE做业务映射：

SELECT COALESCE(email, 'no_email@domain.com') AS safe_email, CASE WHEN email IS NULL THEN '未提供' WHEN email = '' THEN '格式错误' ELSE '有效' END AS email_status FROM users;

5.3 COALESCE的“类型雪崩”：报表金额全部为0

事故：财务日报中所有金额列显示0，但数据库里数据正常。发现SQL中：

SELECT COALESCE(invoice_amount, discount_amount, 0) AS final_amount FROM invoices;

invoice_amount是DECIMAL(10,2)，discount_amount是VARCHAR，COALESCE把两者都转成DOUBLE，精度丢失。

修复：显式CAST保证类型一致：

SELECT COALESCE( CAST(invoice_amount AS DECIMAL(10,2)), CAST(discount_amount AS DECIMAL(10,2)), 0.00 ) AS final_amount FROM invoices;

5.4 搜索CASE的“顺序陷阱”：VIP用户被降级

事故：VIP用户订单在物流系统里显示为“普通订单”，导致配送优先级错误。

根因：CASE WHEN中，status = 1（普通）写在status = 1 AND is_vip = 1（VIP）之前：

CASE WHEN status = 1 THEN '普通订单' -- ✅ 先匹配，VIP也被抓进来 WHEN status = 1 AND is_vip = 1 THEN 'VIP订单' -- ❌ 永远不执行 END

修复：按业务优先级倒序排列，高优先级放前面：

CASE WHEN status = 1 AND is_vip = 1 THEN 'VIP订单' WHEN status = 1 THEN '普通订单' ... END

5.5 简单CASE的“隐式转换”：支付成功率虚高

事故：支付成功率报表显示99.9%，但实际客服反馈失败率很高。

根因：status字段是VARCHAR，但CASE中用数字匹配：

CASE status WHEN 1 THEN 'success' -- 字符串'1'转数字1，匹配成功 WHEN 'failed' THEN 'failed' -- 字符串'failed'不匹配数字1 END

所有status='failed'的记录都进了ELSE分支，被标为'success'。

修复：统一用字符串匹配，或ALTER TABLE改字段类型：

CASE status WHEN '1' THEN 'success' WHEN 'failed' THEN 'failed' ... END

5.6 跨函数组合的“逻辑断层”：优惠券发放错误

事故：满减券发放给所有用户，包括已过期用户。

SQL片段：

SELECT user_id, IF(coupon_valid = 1, COALESCE(coupon_amount, 0), 0 ) AS send_amount FROM users;

问题在于：coupon_valid = 1是布尔表达式，但coupon_valid字段是TINYINT，值可能是0,1,2（2表示“已过期”）。coupon_valid = 1对值为2的记录返回FALSE，但coupon_valid = 2没被处理。

修复：用CASE显式枚举所有状态：

SELECT user_id, CASE coupon_valid WHEN 1 THEN COALESCE(coupon_amount, 0) WHEN 2 THEN 0 -- 已过期 ELSE 0 -- 其他异常 END AS send_amount FROM users;

5.7 ORDER BY中的CASE：索引失效的隐形杀手

事故：订单列表页加载超时，EXPLAIN显示type=ALL（全表扫描）。

问题SQL：

SELECT * FROM orders ORDER BY CASE WHEN priority = 1 THEN 1 WHEN status = 3 THEN 2 -- 已完成订单排第二 ELSE 3 END;

修复：创建函数索引（MySQL 8.0+）或冗余字段：

-- 方案1：添加计算列并建索引 ALTER TABLE orders ADD COLUMN sort_priority TINYINT GENERATED ALWAYS AS ( CASE WHEN priority = 1 THEN 1 WHEN status = 3 THEN 2 ELSE 3 END ) STORED; CREATE INDEX idx_sort_priority ON orders(sort_priority);

5.8 GROUP BY与CASE混合：聚合结果错乱

事故：按地区统计订单量，华东区数据是其他区的3倍。

问题SQL：

SELECT CASE WHEN city IN ('上海','南京','杭州') THEN '华东' WHEN city IN ('北京','天津') THEN '华北' END AS region, COUNT(*) FROM orders GROUP BY region; -- ❌ 别名不能在GROUP BY中用！

修复：重复CASE表达式，或用子查询：

-- ✅ 方案1：重复表达式 GROUP BY CASE WHEN city IN ('上海','南京','杭州') THEN '华东' WHEN city IN ('北京','天津') THEN '华北' END -- ✅ 方案2：子查询（更清晰） SELECT region, COUNT(*) FROM ( SELECT CASE WHEN city IN ('上海','南京','杭州') THEN '华东' WHEN city IN ('北京','天津') THEN '华北' ELSE '其他' END AS region FROM orders ) t GROUP BY region;

5.9 存储过程中的CASE：变量作用域陷阱

事故：存储过程中，CASE WHEN设置的变量在后续语句中为NULL。

问题代码：

DECLARE v_status VARCHAR(20); CASE status_code WHEN 1 THEN SET v_status = 'active'; WHEN 2 THEN SET v_status = 'inactive'; END CASE; SELECT v_status; -- 返回NULL！

根因：CASE语句块内声明的变量作用域仅限该块，外部不可见。

修复：用SET直接赋值，或声明为OUT参数：

SET v_status = CASE status_code WHEN 1 THEN 'active' WHEN 2 THEN 'inactive' ELSE 'unknown' END;

5.10 触发器中的IF：行级操作的原子性破坏

事故：更新用户余额时，触发器中IF判断导致部分更新丢失。

问题触发器：

DELIMITER $$ CREATE TRIGGER update_balance AFTER UPDATE ON users FOR EACH ROW BEGIN IF NEW.balance < 0 THEN INSERT INTO balance_alerts VALUES (NEW.id, 'negative'); END IF; END$$ DELIMITER ;

问题：IF条件为TRUE时执行INSERT，但IF为FALSE时什么也不做——这本身没错，但若触发器中有多个IF，其中一个失败会导致整个事务回滚。

修复：用CASE WHEN保证所有分支都有处理，或用SIGNAL抛出明确错误：

CASE WHEN NEW.balance < 0 THEN INSERT INTO balance_alerts VALUES (NEW.id, 'negative'); WHEN NEW.balance > 100000 THEN INSERT INTO balance_alerts VALUES (NEW.id, 'high_balance'); ELSE -- 显式空操作，避免逻辑缺口 SET @dummy = 0; END CASE;

5.11 JSON字段中的CASE：解析失败静默吞错

事故：用户偏好JSON字段解析后，所有值都是NULL。

问题SQL：

SELECT CASE WHEN JSON_EXTRACT(profile, '$.theme') = '"dark"' THEN 'dark' ELSE 'light' END AS theme_mode FROM users;

JSON_EXTRACT返回带引号的字符串"dark"，而='"dark"'比较的是不带引号的dark，永远不匹配。

修复：用JSON_UNQUOTE或JSON_CONTAINS：

SELECT CASE WHEN JSON_UNQUOTE(JSON_EXTRACT(profile, '$.theme')) = 'dark' THEN 'dark' ELSE 'light' END AS theme_mode FROM users;

5.12 多层嵌套的可维护性崩溃：一个CASE写满一页

事故：运维同事改一个状态码，花了2小时找对应分支，改错一行导致全站订单状态错乱。

现状：一个CASE WHEN写了47行，覆盖12个状态、7种业务线、3个地区规则。

修复：拆分为配置表+JOIN：

-- 创建状态映射表 CREATE TABLE status_mapping ( business_line VARCHAR(20), raw_status VARCHAR(10), display_text VARCHAR(50), priority TINYINT ); -- 查询时JOIN SELECT u.*, m.display_text FROM users u JOIN status_mapping m ON u.business_line = m.business_line AND u.raw_status = m.raw_status WHERE m.business_line = 'ecommerce';

6. 我的条件函数使用铁律：从今天起改变你的SQL习惯

写完这五千多字，我合上笔记本，泡了杯茶。这些内容不是来自文档，而是从一次次线上告警、一张张故障复盘报告、无数个深夜的EXPLAIN分析里抠出来的。现在，我把它们浓缩成三条铁律，贴在我工位的显示器边框上——你也值得这么做。

第一律：NULL不是“空”，是“未知”。所有条件函数的第一行注释必须写明“如何处理NULL”

• IF函数：加AND column IS NOT NULL前置判断
• CASE WHEN：第一个WHEN必须是WHEN column IS NULL
• COALESCE：只用于兜底，不用于业务决策
  这不是教条，是防止你写的SQL在数据质量波动时变成定时炸弹。

第二律：CASE WHEN的WHEN分支数 > 3，立刻停手，画流程图，再决定是拆表还是重构逻辑
我见过太多人把CASE WHEN当if-else链来写，直到第17个WHEN出现时才发现：这根本不是SQL该干的事。数据库擅长集合运算，不擅长复杂状态机。把状态规则抽成配置表，SQL只做关联，既提升性能，又让产品能自主配置——这才是工程师该有的架构思维。

第三律：永远用EXPLAIN验证你的条件函数是否走索引
哪怕只是加了个IF，也要跑一遍EXPLAIN FORMAT=TREE。重点关注：

• possible_keys是否为空
• key是否用了预期索引
• rows是否比不加函数时暴涨
• filtered是否低于10%（说明条件过滤效率低）
  工具不会骗人。你写的每一条SQL，都应该经得起执行计划的拷问。

最后分享一个小技巧：在Navicat或MySQL Workbench里，给所有条件函数加颜色标记。比如IF用黄色背景，CASE WHEN用蓝色边框，COALESCE用绿色下划线——视觉提示比记忆更可靠。上周我靠这个标记，提前发现了同事SQL里一个漏掉的ELSE分支，避免了一次数据错乱。

条件判断函数不是语法糖，它是你和数据库对话的语言。说清楚，它才给你准确答案；说模糊，它就按自己的逻辑给你“合理”结果——而那个结果，往往就是线上事故的起点。