MySQL或SQL Server存储过程中，IF或CASE中直接用=、!=判断NULL会导致分支失效：因NULL参与比较返回UNKNOWN，既不进THEN也不进ELSE，造成逻辑中断、更新不生效、默认值未兜底等静默错误；必须显式使用IS NULL/IS NOT NULL或COALESCE预处理。
存储过程中NULL导致条件分支失效的典型表现
在MySQL或SQL Server存储过程中，IF 或 CASE 里直接用 =、!= 判断参数是否为NULL，几乎必然漏掉分支。比如写 IF @status != 'done'，当 @status 是 NULL 时，整个表达式结果是 UNKNOWN，不进 THEN 也不进 ELSE（某些方言下等效于跳过），逻辑就断了。
常见症状包括：存储过程执行无报错但返回空结果、更新语句没生效、日志中缺失预期记录、默认值未兜底。
- 所有涉及比较的判断必须显式拆出
IS NULL或IS NOT NULL分支 - 不要依赖
NOT (@x = 'val')等价于@x != 'val'—— 两者在@x为NULL时都返回UNKNOWN - SQL Server中
ANSI_NULLS OFF虽能绕过，但属已弃用行为，线上禁用
参数校验阶段必须用COALESCE或CASE预处理
传入的 IN 参数一旦为 NULL，后续参与算术、字符串拼接、比较都会静默传播为 NULL。例如：SET @msg = 'Order ' + CAST(@order_id AS CHAR)，若 @order_id 是 NULL，@msg 直接变 NULL，不报错也不提示。
正确做法是在参数进入业务逻辑前统一兜底：
- 数值类参数：用
COALESCE(@param, 0)或IFNULL(@param, 0)（MySQL） - 字符串类参数：用
COALESCE(@param, '')，避免后续CONCAT()或+运算中断 - 布尔逻辑类：别用
@flag = 1判断，改用COALESCE(@flag, 0) = 1 - 注意：不能只在最终输出处补，默认值必须在计算链最上游注入
WHERE子句中NULL引发的索引失效与结果遗漏
存储过程里拼接动态SQL或写固定查询时，WHERE col != @val 这种写法在 @val 为 NULL 时不仅逻辑错，还会让优化器放弃使用 col 上的索引——因为 col != NULL 永远不成立，优化器可能退化为全表扫描。
更隐蔽的是 IN / NOT IN 子查询场景：如果子查询结果含 NULL，整个 NOT IN 条件直接判定为 UNKNOWN，查不到任何数据。
- 固定条件优先用
IS NULL/IS NOT NULL显式隔离 - 动态参数必须配合
COALESCE(@param, 'dummy_value')再参与比较，确保运算始终有确定结果 - 涉及子查询的否定逻辑，一律改用
NOT EXISTS或LEFT JOIN ... IS NULL，避开NOT IN的三值陷阱 - MySQL 8.0+ 可考虑
安全等于符，但注意它不走索引，仅适合小数据量兜底
输出参数和RETURN值被NULL静默覆盖的风险
声明为 OUT 或 OUTPUT 的参数，如果过程中某步赋值表达式含 NULL（如 SELECT @result := col FROM t WHERE id = @id，而该行 col 为 NULL），则 @result 直接变成 NULL，调用方拿到的就是空值，且无任何异常提示。
RETURN值同理：若过程末尾写 RETURN @code，而 @code 之前被设为 NULL，调用方收到的返回码就是 NULL，极易被上层代码忽略。
- 所有
OUT参数赋值前必须做非空校验，例如：SET @output = COALESCE(@temp_result, -1) - RETURN前强制类型转换：
RETURN IFNULL(@ret_code, 0) - 关键路径建议加日志：用
SELECT CONCAT('DEBUG: output=', IFNULL(@output, 'NULL'));快速定位静默NULL点 - SQL Server中可启用
SET ANSI_WARNINGS ON捕获部分隐式NULL赋值警告（但不覆盖所有场景）
NULL在存储过程里不报错、不中断、不提醒，只悄悄让逻辑偏航——最危险的不是它出现，而是你根本没意识到它已经混进了计算链的任意一环。
