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这种无效赋值也算“被更新”。它不能替代值比对。
- 必须叠加显式比较：
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或统一类型。
