必须改用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 != NEW.status在OLD.status = 'active'、NEW.status = NULL时结果是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，必须在原子操作层面就拦截，晚一步就不可逆。
