如何在触发器中判断具体哪个字段被更新_UPDATE(column)逻辑应用

sql Server 的 UPDATE() 函数仅检测列是否出现在 SET 子句中，不判断值是否变化；必须用于 if 或 WHERE 中，参数为列名，对 NULL 赋值也返回 1，对计算列等始终返回 0。

SQL Server 的 UPDATE() 函数怎么用才靠谱

UPDATE() 是 SQL Server 触发器里判断“某列是否在本次 UPDATE 语句中被显式修改”的唯一内置方式。它不看值变没变，只看列有没有出现在 SET 子句里——这点非常关键，很多人误以为它检测“值是否变化”，结果逻辑出错。

实操建议：

• UPDATE() 必须写在 IF 或 WHERE 中，不能单独执行；参数必须是列名（如 UPDATE(Email)），不能是变量或表达式
• 对 NULL 值赋值也算“被更新”，比如 SET Email = NULL 会让 UPDATE(Email) 返回 1
• 如果 UPDATE 语句里根本没提某列（哪怕它实际值变了），UPDATE(columnName) 就返回 0
• 注意：它对计算列、标识列、ROWVERSION 列始终返回 0，哪怕它们被间接影响

mysql 没有 UPDATE()，得靠 OLD 和 NEW 手动比

MySQL 触发器没有等价函数，必须用 OLD.column_name != NEW.column_name（或更严谨地处理 NULL）来判断字段值是否真变了。这和 SQL Server 的语义完全不同——这里比的是“值是否不同”，不是“是否被 SET”。

实操建议：

• 直接写 OLD.email != NEW.email 在 NULL 场景下会失效（因为 NULL != NULL 为 UNKNOWN），必须用 OLD.email NEW.email = 0 或显式判断 IS NULL
• 字符串比较要注意大小写和末尾空格，建议统一用 BINARY 或指定 collation 避免隐式转换陷阱
• 如果字段类型是 json、POINT 等复杂类型，!= 可能不准确，优先用 JSON_CONTAINS() + JSON_EXTRACT() 拆解比对关键路径

postgresql 用 tg_argv 或条件触发器更灵活，但别滥用

PostgreSQL 没有内置字段级变更检测函数，常规做法是在触发器函数里手动比较 OLD.col 和 NEW.col。不过从 9.0 起支持条件触发器（WHEN (NEW.col IS DISTINCT FROM OLD.col)），语法简洁且天然处理 NULL。

实操建议：

• 条件触发器的 WHEN 子句里只能用 OLD/NEW 字段，不能调函数或子查询；想复用逻辑就封装成 IMMUTABLE 函数
• 如果要同时监控多个字段且逻辑不同，别堆一个大触发器，拆成多个独立触发器更易维护、性能也更好（避免全量扫描）
• tg_argv 可传参给触发器函数，适合同一函数复用于不同表/字段场景，但参数是文本数组，需手动解析，容易出错，非必要不推荐

跨数据库移植时最容易栽的三个坑

写触发器时一旦考虑兼容性，UPDATE() 这类方言特性就是雷区。同一套业务逻辑在不同数据库上行为可能完全相反。

常见错误现象：

• SQL Server 里 UPDATE(name) 为真 → MySQL 里 OLD.name != NEW.name 却为假（比如只改了空格或大小写）
• PostgreSQL 条件触发器用了 IS DISTINCT FROM，迁到 SQL Server 就报语法错误
• 在 MySQL 里用 CONCAT(OLD.col, '') != CONCAT(NEW.col, '') 模拟非空安全比较，结果遇到 TEXT 字段超长截断，误判为“未变更”

真正麻烦的不是语法差异，而是语义差异本身：有的检测“是否被提及”，有的检测“是否真变”，有的甚至要区分“是否由用户发起”。选哪种，得先想清楚你到底要响应什么事件——是业务层明确改了邮箱，还是数据最终值变了，这决定了底层怎么写，而不是反过来。