MySQL用OLD.col <=> NEW.col、PostgreSQL用IS DISTINCT FROM、SQL Server需叠加UPDATE()与显式值比对，三者均须规避NULL误判、类型隐式转换及触发器内查表。

MySQL里用<=>代替!=判断字段是否真变

直接写OLD.col != NEW.col在任一值为NULL时返回UNKNOWN，导致IF条件不成立，变更被漏掉。比如email从NULL变成'a@b.com'，!=结果不是TRUE也不是FALSE，整个判断失效。

必须用<=>（安全等于）：它把NULL当普通值处理，NULL <=> NULL返回TRUE，NULL <=> 'x'返回FALSE，逻辑可预测。

• IF NOT (OLD.status <=> NEW.status) —— 精准捕获status值变化
• 多个字段合并判断时，别嵌套IF，写成：IF NOT (OLD.a <=> NEW.a AND OLD.b <=> NEW.b)
• 字符串字段若需忽略尾部空格或大小写，先TRIM()或加BINARY：BINARY TRIM(OLD.name) <=> BINARY TRIM(NEW.name)

PostgreSQL必须用IS DISTINCT FROM

在 PostgreSQL 里，!=一旦碰上NULL，同样靠不住：NULL != NULL返回的不是布尔值，而是NULL，结果就是IF代码块会被直接跳过。即便字段类型是JSONB或ARRAY，处理方式也一样，应该改用IS DISTINCT FROM。这个写法原生就支持复杂类型比较，不需要先做序列化。

• IF OLD.phone IS DISTINCT FROM NEW.phone THEN ... —— 正确覆盖NULL→'123'、'123'→NULL、'123'→'456'三类变更
• 不要用COALESCE(OLD.col, '') != COALESCE(NEW.col, '')，除非你确认替换值''不会和业务真实值冲突
• 如果字段允许NULL且类型为timestamp，注意时区和微秒精度，必要时显式AT TIME ZONE对齐

SQL Server里UPDATE()只看SET子句，不看值变没变

UPDATE('email')返回TRUE，本质上只能说明在UPDATE ... SET email = ...这条语句里出现了email字段。至于值到底有没有变化，它并不负责判断。哪怕是SET email = deleted.email这种实际上没有改动结果的赋值，也一样会被算作“更新了”。所以，UPDATE('email')不能拿来替代实际的值比对。

• 必须叠加显式比较：IF UPDATE(email) AND (OLD.email <> NEW.email OR (OLD.email IS NULL) <> (NEW.email IS NULL))
• 更稳妥的做法是先用UPDATE()快速过滤没被SET的字段，再用IS NULL/IS NOT NULL组合判断真实差异
• 注意OLD/NEW在SQL Server中是deleted和inserted临时表，需SELECT TOP 1 @old_val = col FROM deleted取值，不能直接deleted.col引用

所有数据库都得避开触发器内查表和拼JSON

批量更新100行，触发器里写SELECT COUNT(*) FROM logs WHERE user_id = NEW.user_id，就会执行100次查询——性能断崖下跌。想发通知或记日志，别在触发器里做耗时操作。

• 需要关联查询或HTTP请求的逻辑，一律挪到应用层或异步任务
• 记录变更详情时，别在触发器里拼JSON_OBJECT('old', OLD.col, 'new', NEW.col)——MySQL 5.7+虽支持，但性能损耗明显
• PostgreSQL用NOTIFY只传主键：NOTIFY order_status_change, NEW.id::text，监听端自己查表还原上下文
• 历史表设计别照搬原表结构，主键要设为自增id，另加op_type、op_time、op_user字段，避免INSERT/UPDATE冲突

真正变化的字段识别，核心就两点：一是用数据库原生的空安全比较（<=> / IS DISTINCT FROM），二是彻底放弃UPDATE()这类语法级函数去代替值比对。容易被忽略的是类型隐式转换——比如INT字段被SET成字符串'123'，某些版本会转成数字再比，有些不会，行为不一致，必须显式CAST或统一类型。