必须显式比对old/new字段值，如if old.id_card != new.id_card or old.phone != new.phone then；注意null安全比较（mysql用，postgresql用is distinct from），避免在触发器内执行http或写文件等高风险操作。
触发器里怎么捕获敏感字段的变更
触发器本身不自动知道哪些字段“敏感”，必须显式比对 OLD.字段名 和 NEW.字段名。比如用户表中 id_card、phone、email 是敏感字段，就得逐个写判断逻辑：
IF OLD.id_card != NEW.id_card OR OLD.phone != NEW.phone THEN -- 发起告警动作 END IF;
注意：MySQL 中 != 对 NULL 不成立，要用 NOT (OLD.id_card NEW.id_card)；PostgreSQL 可用 IS DISTINCT FROM 更安全。
常见坑：UPDATE t SET name='x' WHERE id=1 却没改敏感字段，但触发器仍执行了——说明没做字段级过滤，纯靠 WHERE 条件无法规避。
告警动作该放在触发器里还是外面
直接在触发器里发 HTTP 请求或写日志文件，风险极高：事务未提交时网络超时、磁盘满、权限不足都会导致整个 UPDATE 失败。绝大多数生产环境禁止这么做。
更稳妥的做法是只写入一张轻量告警队列表（如 alert_log），再由外部定时任务或监听进程消费：
INSERT INTO alert_log(table_name, row_id, changed_fields, updated_at) VALUES ('user', NEW.id, 'phone,id_card', NOW());- 避免在触发器中调用存储过程封装复杂逻辑，尤其含事务或锁操作
- PostgreSQL 的
pg_notify()可异步通知监听端，MySQL 则依赖轮询或 binlog 解析
不同数据库对触发器能力的硬限制
MySQL 的 BEFORE UPDATE 触发器不能修改 NEW 值以外的数据，也无法查询当前表（会报 ERROR 1442）；而 PostgreSQL 允许在触发器函数里执行任意 SQL，包括跨表查询和 INSERT。
性能影响明显：每行更新都触发一次逻辑，若敏感字段判断涉及子查询或函数调用（如 SHA2(OLD.email, 256)），写入吞吐量可能下降 30%+。
关键差异点：
- MySQL 不支持语句级触发器（STATEMENT-level），只能按行触发
- SQL Server 的
INSTEAD OF触发器可拦截并重写操作，但 MySQL/PostgreSQL 没这机制 - 所有数据库中，触发器都无法捕获批量 UPDATE 中被 SET 但实际未变的字段（比如
SET phone=phone）
为什么审计日志比触发器更适合敏感字段监控
触发器只响应 DML，漏掉 TRUNCATE、DROP、GRANT 等高危操作；且一旦触发器出错，业务写入直接失败。真正需要告警的场景，往往要覆盖「谁、何时、从哪台机器、改了什么、改前改后值」——这些信息触发器拿不到完整上下文。
推荐组合方案：
- 用数据库原生审计插件（如 MySQL Enterprise Audit、PostgreSQL
pgaudit）捕获全量变更 - 配合日志分析工具（如 ELK）设置字段级告警规则，比如匹配
"column": "id_card"+"action": "UPDATE" - 触发器只作为兜底手段：当审计插件不可用或需实时拦截时，才启用最小化逻辑
最常被忽略的是权限控制——即使触发器写了告警，如果 alert_log 表可被普通应用用户 DELETE，那告警记录本身就成了新风险点。
