MySQL中NULL导致=和IN失效，因三值逻辑返回UNKNOWN；应改用IS NULL、COALESCE或显式初始化变量，并在触发器/循环中严格处理空值。
MySQL 存储过程里 NULL 一出现，= 和 IN 就失效
MySQL 对 NULL 的比较是三值逻辑：任何与 NULL 的等值判断（=、!=、IN）都返回 UNKNOWN，不是 TRUE 也不是 FALSE。所以你在存储过程中写 IF my_col = 'A' THEN，哪怕 my_col 是 NULL，这个分支也进不去——它根本没被判定为真，连“假”都算不上。
常见错误现象：
• 查询条件加了 WHERE status = 'active'，但 status 为 NULL 的行永远查不到
• IF var_name IN ('a','b') 在 var_name 是 NULL 时静默跳过
• SET @sum = @sum + amount; 遇到 amount 为 NULL，整个 @sum 变成 NULL
- 别用
=或IN直接比可能为NULL的变量，改用IS NULL或IS NOT NULL显式判断 - 聚合计算前先用
COALESCE(amount, 0)把空值转成默认值，避免污染结果 - 在
IF条件里嵌套判断，比如IF var_name IS NOT NULL AND var_name IN ('a','b') THEN
IFNULL() 和 COALESCE() 看似一样，但行为有关键区别
IFNULL(a, b) 是 MySQL 特有函数，只接受两个参数；COALESCE(a, b, c, ...) 是 SQL 标准函数，支持多参数，返回第一个非 NULL 值。两者都常用于防错，但选错会影响可读性和移植性。
-
IFNULL()性能略优（内部优化），但换到 PostgreSQL 或 SQL Server 就报错，不推荐在跨库场景用 -
COALESCE()第一个非NULL参数决定返回值类型，如果传入COALESCE(int_col, 'N/A')，MySQL 会把整数转成字符串，可能引发隐式转换警告 - 在存储过程变量赋值中，优先用
COALESCE(@val, 0)而不是IFNULL(@val, 0)，更易维护也更标准
存储过程里 SELECT ... INTO 遇到空结果集，变量不会清空
这是最隐蔽的坑：SELECT col INTO @var FROM t WHERE id = 123; 如果没查到数据，@var 不会变成 NULL，而是保持上一次的值。后续逻辑如果依赖 “查不到就等于空”，就会出错。
- 必须显式初始化变量：
SET @var = NULL;再执行SELECT ... INTO - 或者改用
COALESCE((SELECT col FROM t WHERE id = 123), 'default')，让子查询结果直接参与空值处理 - 检查是否查到数据，可用
SELECT FOUND_ROWS() > 0或在SELECT后加ROW_COUNT()判断
触发器或循环中漏判 NULL，会导致整个事务中断
在 BEFORE INSERT 触发器里，如果对新字段做 IF NEW.phone = '138...' THEN，而 phone 允许为空且本次插入为 NULL，这个条件不成立，但更危险的是——如果你接着写了 SET NEW.phone = UPPER(NEW.phone);，MySQL 会把 UPPER(NULL) 当作 NULL，没问题；但若换成 CONCAT('prefix-', NEW.phone)，结果就是 NULL，可能违反非空约束，导致插入失败。
- 所有对
NEW.或OLD.字段的操作，只要涉及函数或拼接，先用COALESCE(NEW.field, '')包一层 - 循环中（如
WHILE）用游标取值后，立刻检查done标志位，而不是依赖字段是否为NULL判断结束 - 不要在触发器里依赖客户端传来的默认值逻辑，服务端必须自己兜底
空值不是“没有值”，是“未知值”——这个语义差异在存储过程这种强逻辑场景里，会放大成难以复现的运行时偏差。最稳妥的做法，是把每个可能为 NULL 的变量，在使用前都过一遍 COALESCE()，哪怕看起来“不可能为空”。
