SQL中NULL导致逻辑失效的根本原因是三值逻辑：@var = NULL恒返回UNKNOWN，而IF和WHERE只响应TRUE；需用IS NULL、COALESCE、OR条件等显式处理。
IF 条件里写 @var = NULL 为什么永远不进分支
因为 SQL 的三值逻辑中，@var = NULL 恒返回 UNKNOWN，而 IF 只响应 TRUE；UNKNOWN 和 FALSE 都被跳过。这不是 bug，是标准行为。
常见错误现象：存储过程执行时某段逻辑“静默跳过”，查日志没报错、也没效果，最后发现是状态变量为 NULL 导致整个判断失效。
- 想单独捕获
NULL：必须写IF @status IS NULL - 想把
NULL视为一种有效状态（比如“未指定”）：用IF @status = 'active' OR @status IS NULL - 只想处理明确等于某个值的情况：直接写
IF @status = 'active'即可，不用额外兜底——NULL本来就不该进这个分支
WHERE 中参数为 NULL 时如何安全跳过该条件
典型场景是前端传了 @name 但没传 @age，后端希望只按 name 过滤，age 条件自动失效。
安全写法是把“参数为空”和“字段匹配”拆成两个独立逻辑，用 OR 连接：
WHERE (@name IS NULL OR name = @name) AND (@age IS NULL OR age = @age)
千万不能写成 WHERE name = ISNULL(@name, name)——表面简洁，但 ISNULL(@name, name) 会让优化器放弃使用 name 列上的索引，性能可能断崖下跌。
- 顺序很重要：带
DEFAULT NULL的参数必须放在存储过程参数列表末尾，否则调用时跳过中间参数会报错expects parameter '@p2', which was not supplied - 如果参数来自用户输入且需校验格式，建议在
WHERE前先做IF @age 类似的清洗
计算或拼接时遇到 NULL 导致结果全为 NULL 怎么办
SQL 中任何值与 NULL 做算术、字符串连接或比较，结果几乎总是 NULL。“未知 + 10 = 未知”，不是报错，而是静默传播。
数值清洗必须显式兜底：
- 错误：
SET @total = @price + @discount→ 任一为NULL，@total就是NULL - 正确：
SET @total = COALESCE(@price, 0) + COALESCE(@discount, 0) - 字符串拼接同理：
COALESCE(first_name, '') + ' ' + COALESCE(last_name, '') - 触发器里尤其危险：
CONCAT('ID:', id, '-', name)中任一字段为NULL，结果就是NULL，可能违反NOT NULL约束导致插入失败
IN/NOT IN 里混入 NULL 为什么查不到数据
NOT IN (1, 2, NULL) 等价于 col != 1 AND col != 2 AND col != NULL，最后一项恒为 UNKNOWN，整个 AND 结果必为 UNKNOWN，WHERE 直接丢弃整行。
动态拼接时更隐蔽：如果 @list 来自含 NULL 的临时表，WHERE col NOT IN (@list) 可能返回空结果集，毫无征兆。
- 替代方案一：
NOT EXISTS (SELECT 1 FROM @temp t WHERE t.val = col AND t.val IS NOT NULL) - 替代方案二：先清理
NULL，再拼接：WHERE col NOT IN (SELECT v FROM @temp WHERE v IS NOT NULL) - 永远别在
IN子句里直接用未经过滤的用户输入或临时表结果
NULL 不是值，是状态；它不会报错，只会悄悄让逻辑失效。最危险的不是它出现，而是你没意识到它正在影响判断路径、计算结果或索引选择。
