最可靠方式是在AFTER UPDATE触发器中用INSERTED和DELETED表显式比对关键字段，注意NULL处理、异步报警、避免耗时操作；MySQL用BEFORE UPDATE+SIGNAL做强校验；PostgreSQL可用hstore差分；跨库同步时触发器易漏报，需在源端落表或中间件校验。
触发器里怎么捕获字段变更并报警
直接在 AFTER UPDATE 触发器中用 INSERTED 和 DELETED 临时表做字段级比对，是最可靠的方式。SQL Server 不支持像 PostgreSQL 那样用 OLD.* / NEW.* 的简写，必须显式列出字段。
常见错误是只比对主键或忽略 NULL 值：比如 ISNULL(i.status, '') != ISNULL(d.status, '') 必须加，否则 NULL != 'active' 判定为 UNKNOWN，整个条件失效。
- 报警动作建议走异步：用
sp_send_dbmail或写入专用日志表 + 外部轮询，避免阻塞业务更新 - 只监控关键字段：比如订单表只盯
order_status、payment_amount、shipping_address_id，别全表扫 - 触发器里禁止调用耗时操作（如远程 API、大表 JOIN），否则 UPDATE 会卡住
MySQL 中用 BEFORE UPDATE 检查一致性并中断修改
MySQL 的 BEFORE UPDATE 触发器可以主动抛出错误来阻止不合规变更，比 SQL Server 更适合强校验场景。核心是用 SIGNAL SQLSTATE '45000' 并附带明确提示。
例如要求 end_time 必须晚于 start_time，且两者都非空：
IF NEW.start_time IS NOT NULL AND NEW.end_time IS NOT NULL AND NEW.end_time
- 注意
NEW.引用的是即将写入的值，OLD.是原值，不能反着用 - 字符串比较要小心排序规则：比如
utf8mb4_0900_as_cs下'A' != 'a'，而默认规则可能忽略大小写 - 不要在触发器里改
NEW.字段再继续——逻辑易混乱，应由应用层或存储过程预处理
PostgreSQL 的触发器函数怎么返回变更字段列表
PostgreSQL 触发器函数需定义为 RETURNS TRIGGER，并在函数体内用 hstore(NEW.*) - hstore(OLD.*) 快速提取差异字段。前提是已启用 hstore 扩展：CREATE EXTENSION IF NOT EXISTS hstore;
示例片段（返回 JSON 格式变更摘要）：
SELECT json_agg(json_build_object('field', key, 'old', OLD.*->key, 'new', NEW.*->key))
FROM each(hstore(NEW.*) - hstore(OLD.*)) AS diff(key, value);
-
hstore对 NULL 值处理自然，无需额外COALESCE - 若表字段多但只关心几个，建议先用
ROW(NEW.f1, NEW.f2) IS DISTINCT FROM ROW(OLD.f1, OLD.f2)做前置判断，避免构造全量 hstore 开销 - 该方式不适用于含数组、JSONB、几何类型等不可 hstore 化的字段，需单独处理
跨库同步时触发器报警为什么总漏报
本质问题：很多同步工具（如 Canal、Debezium、SQL Server Replication）不触发目标端的触发器，或只触发但跳过某些上下文（如 CONTEXT_INFO 或会话级标志）。报警逻辑如果依赖触发器执行，就会静默失效。
- 验证方法：手动在目标库执行
UPDATE，看报警是否触发；若能，但同步过来的不报，基本确认是同步机制绕过了触发器 - 补救方案：把检查逻辑下沉到同步中间件（如 Flink CDC 中加自定义校验算子），或在源端触发器写变更记录表，再由独立服务监听该表发警报
- 特别注意
SET IDENTITY_INSERT、DISABLE TRIGGER等同步脚本常用语句，它们会让触发器完全失活
字段级变更检查本身不难，难的是在分布式、多通道、带缓存的现代架构里，确保报警路径不被任意一环吃掉或延迟。真正上线前，务必用真实同步流量压测报警链路。
