在 SQL 中，BEFORE UPDATE 触发器是实现数据变更审计最常用、最可靠的方式之一——它能在更新真正执行前捕获 OLD 值（变更前） 和 NEW 值（变更后），从而精准记录“谁改了什么、从什么变成什么”。
触发器里怎么拿到旧值和新值
不同数据库语法略有差异，但核心逻辑一致：
- MySQL / PostgreSQL：直接用 OLD.字段名 和 NEW.字段名 引用；
- SQL Server：通过 INSERTED（相当于 NEW）和 DELETED（相当于 OLD）临时表访问；
- Oracle：使用 :OLD.字段名 和 :NEW.字段名（注意冒号前缀）。
关键点：只有字段被显式更新时，NEW.字段名 才反映新值；未在 SET 子句中出现的字段，NEW.字段名 仍等于 OLD.字段名。所以判断“是否真修改”，不能只看 NEW 是否非空，而要显式比较 OLD.col != NEW.col（注意 NULL 安全比较）。
审计日志表设计要兼顾可读性与查询效率
一张典型的审计表至少包含：
- audit_id（主键，自增或 UUID）；
- table_name、row_id（标识哪张表、哪一行）；
- operation（如 'UPDATE'）、updated_at、updated_by（需配合应用层传入或数据库上下文获取）；
- column_name、old_value、new_value（建议用 TEXT 或 JSON 类型存储，避免字段长度限制）。
如果业务要求追溯到具体字段级变更，推荐“一行一字段变更”的扁平结构（即每次更新多个字段，生成多条审计记录），而不是单行存所有变化的宽表——前者更易按字段筛选、统计变更频次，也方便对接下游分析系统。
避免常见陷阱：NULL、LOB、性能与权限
实际落地时容易踩坑：
- NULL 比较要小心：OLD.col = NEW.col 在任一为 NULL 时返回 UNKNOWN，应写成 (OLD.col IS NOT DISTINCT FROM NEW.col)（PostgreSQL/SQL Server）或手动判空（MySQL 用 IFNULL 或 安全等于）；
- 大字段（BLOB/TEXT/JSON）不建议全量记录：可记录哈希值（如 SHA256），或仅当长度≤1000 时才存原文，否则日志表迅速膨胀；
- 触发器本身不能太重：避免在触发器里调远程服务、复杂计算或跨库写入；审计写入尽量用异步队列或延迟落盘（如 MySQL 的 INSERT DELAYED 已弃用，可用应用层缓冲）；
- 确保触发器拥有目标审计表的 INSERT 权限，且应用账号执行 UPDATE 时能成功触发——权限不足会导致整个 UPDATE 失败（BEFORE 触发器报错会中断事务）。
一个轻量实用的 MySQL 审计触发器示例
以用户表 users(id, name, email, status) 为例：
DELIMITER $$
CREATE TRIGGER users_audit_before_update
BEFORE UPDATE ON users
FOR EACH ROW
BEGIN
IF OLD.name != NEW.name OR (OLD.name IS NULL) != (NEW.name IS NULL) THEN
INSERT INTO audit_log (table_name, row_id, column_name, old_value, new_value, updated_at, updated_by)
VALUES ('users', OLD.id, 'name', OLD.name, NEW.name, NOW(), USER());
END IF;
IF OLD.email != NEW.email OR (OLD.email IS NULL) != (NEW.email IS NULL) THEN
INSERT INTO audit_log (table_name, row_id, column_name, old_value, new_value, updated_at, updated_by)
VALUES ('users', OLD.id, 'email', OLD.email, NEW.email, NOW(), USER());
END IF;
END$$
DELIMITER ;
这个例子只对 name 和 email 字段做变更检测，逻辑清晰、易于维护。生产环境可封装为通用存储过程，或用工具自动生成各表触发器。
