得用IS DISTINCT FROM（PostgreSQL）或者显式拆解（SQL Server/MySQL）才行。为啥呢？因为=和!=遇到NULL的时候会返回UNKNOWN，这在WHERE或者WHEN里就会被当成不匹配，然后就漏判了。而IS DISTINCT FROM把NULL当成确定值，它能准确地识别出NULL和非NULL以及NULL和NULL之间的差异。

UPDATE触发器里用=判断字段变化，为什么总漏掉NULL变更

由于=和!=在遇到NULL时，都会返回UNKNOWN，而WHERE或WHEN子句只认TRUE，UNKNOWN就相当于不匹配。举个例子，当OLD.status = 'active'、NEW.status = NULL时，OLD.status != NEW.status的结果是UNKNOWN，那么整行就会直接被跳过。

必须改用IS DISTINCT FROM（PostgreSQL）或显式拆解（SQL Server/MySQL）：

• PostgreSQL：直接写OLD.col IS DISTINCT FROM NEW.col，它把NULL当确定值处理，NULL IS DISTINCT FROM 'x'为TRUE，NULL IS DISTINCT FROM NULL为FALSE
• SQL Server：用ISNULL(OLD.col, '') != ISNULL(NEW.col, '')——但注意这会把''和NULL混为一谈，仅适用于业务上允许这种等价的场景
• MySQL：用安全等于操作符<=>，OLD.col <=> NEW.col返回0（不等）或1（相等），NULL <=> NULL返回1

SQL Server触发器中字符串拼接一碰NULL就整个变NULL

这是标准行为，不是Bug：INSERTED.name + ' - ' + INSERTED.code只要任意一端是NULL，结果就是NULL，不是空字符串。后续插入或日志记录可能因NOT NULL约束失败，且不会报具体哪一列出问题。

正确做法是每个参与拼接的字段单独用ISNULL()兜底：

• ISNULL(INSERTED.name, '') + ' - ' + ISNULL(INSERTED.code, '')
• 别写成ISNULL(INSERTED.name + ' - ' + INSERTED.code, '')——表达式在进ISNULL前已崩了
• ISNULL第二参数类型必须兼容第一参数：字段是INT，就不能写ISNULL(age, 'N/A')，否则隐式转换报错

MySQL触发器里用IFNULL()处理计算字段，但WHERE过滤右表NULL时又崩了

LEFT JOIN后在WHERE里加右表条件（如o.status = 'paid'），会把左表原本该保留的NULL行全过滤掉，等效于INNER JOIN。这不是触发器的问题，是JOIN语义本身导致的。

修复关键在位置，不是函数：

• 右表过滤必须写进ON子句：LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid'
• 若真要查“没订单的用户”，用WHERE o.id IS NULL，不是WHERE o.status = NULL
• 计算字段仍需IFNULL()兜底：SET total = IFNULL(price, 0) * IFNULL(qty, 0)，否则NULL * 5还是NULL

COALESCE能跨库，但触发器里别无脑替换ISNULL/IFNULL

COALESCE()确实兼容所有主流数据库，但触发器对性能和确定性要求更高。它要逐个求值直到第一个非NULL，而ISNULL()（SQL Server）和IFNULL()（MySQL）是原生双参数函数，不推导类型、不短路求值，更轻量。

选哪个看场景：

• 简单兜底（字段为空就填0或''）：优先用ISNULL(col, 0)或IFNULL(col, '')
• 多级fallback（比如先试配置表字段，再试默认值）：才用COALESCE(config_val, default_val)
• 类型混用要小心：COALESCE(input_name, 123)在MySQL可能隐式转字符串导致截断，不如明确写COALESCE(input_name, '123')

实际写触发器时，最易忽略的是：NULL比较必须从语义层重写逻辑，不能靠函数临时包裹；而拼接和计算中的NULL，必须在原子操作层面就拦截，晚一步就不可逆。

《夸克》非常好用的免费AI浏览器

下载APP查看