MySQL存储过程中判空必须用IS NULL而非= NULL，因NULL比较返回UNKNOWN；变量未匹配时自动为NULL；IFNULL轻量双参，COALESCE标准多参但类型严格；LEFT JOIN过滤右表条件须放ON子句；游标中NULL字段需用IFNULL清洗。
存储过程中不能用 = NULL 判断变量是否为空
在 MySQL 存储过程里，IF var = NULL THEN 永远不会进入分支——因为 NULL = NULL 返回的是 UNKNOWN，不是 TRUE，而 IF 只响应 TRUE。这是从应用层逻辑直觉迁移过来最容易踩的坑。
正确写法必须用 IS NULL：
IF my_var IS NULL THEN SELECT 'it is null'; ELSE SELECT 'not null'; END IF;
-
IS NOT NULL同理，不能写成!= NULL或NULL - 如果变量是通过
SELECT ... INTO赋值的，且查询没匹配到行，该变量会自动设为NULL，这是隐式行为，需提前意识到 - 声明时带默认值（如
DECLARE my_var INT DEFAULT 0）能减少后续判空负担，但不改变已有 NULL 的语义
IFNULL() 和 COALESCE() 在存储过程里怎么选
两者都能兜底，但适用场景不同：前者快、轻量、双参数；后者标准、灵活、多参数，但类型推导更严格。
常见用法：
SET display_name = IFNULL(input_name, 'Anonymous'); -- 简单 fallback
SET final_price = COALESCE(price_override, base_price, 0); -- 多级 fallback
-
IFNULL()是 MySQL 原生函数，在存储过程里性能略优，且不会因类型不一致报错（比如IFNULL('123', 456)自动转字符串） -
COALESCE()要求所有参数类型兼容，COALESCE(phone, email, 123)可能触发隐式转换或报错，尤其当字段是VARCHAR而兜底值是数字时 - 在赋值语句（
SET）、条件表达式（IF内部）、甚至游标循环中都可直接使用，无语法限制
LEFT JOIN 后在存储过程中过滤右表字段要特别小心
存储过程里封装复杂查询时，容易把 LEFT JOIN 后对右表字段的过滤写进 WHERE，结果让 LEFT JOIN 变成 INNER JOIN，丢失左表无匹配的记录。
错误示范（在存储过程的 SELECT 里）：
SELECT u.name, o.amount FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid';
正确做法是把右表条件移到 ON 子句：
SELECT u.name, o.amount FROM users u LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid';
- 即使
o.status是NULL，这一行仍保留，o.amount显示为NULL，符合LEFT JOIN本意 - 若真需要排除右表为
NULL的行，应显式加AND o.id IS NOT NULL，而不是依赖WHERE隐式过滤 - 这个陷阱在动态拼 SQL 的存储过程中更隐蔽——拼接时容易把条件统一塞进
WHERE字符串里
游标遍历时遇到 NULL 字段的处理要点
用游标遍历结果集时，字段值可能为 NULL，直接参与计算或拼接会静默失效（比如 CONCAT(name, ' ', surname) 整个变 NULL）。
- FETCH 到的变量本身可以是
NULL，判断方式仍是IF name_var IS NULL - 拼接前务必用
IFNULL(name_var, '')清洗，否则CONCAT(IFNULL(name_var, ''), ' ', IFNULL(surname_var, ''))才安全 - 聚合类逻辑（如累加金额）别直接写
total := total + amount_var，应改为total := total + IFNULL(amount_var, 0) - 注意游标结束标志（
NOT FOUNDhandler）和字段NULL是两回事：前者表示无更多行，后者只是当前行某个字段缺失
实际写存储过程时，最易被忽略的是：NULL 判定逻辑一旦混进条件分支或动态 SQL 拼接，很难靠日志一眼看出问题。建议所有涉及变量判空的地方，统一用 IS NULL，所有参与计算或输出的字段，优先套一层 IFNULL()——宁可多写，别省这一步。
