MySQL 的 BEFORE UPDATE 触发器是唯一能安全读取完整 OLD 行的时机，用于记录修改前值；PostgreSQL 需用 jsonb_build_object 构造快照，审计日志须含表名、操作类型、主键、时间戳、用户及字段级差异。
MySQL 中用 BEFORE UPDATE TRIGGER 捕获旧值
TRIGGER 本身不直接暴露 OLD 和 NEW 以外的数据，但 MySQL 的 BEFORE UPDATE 触发器能安全读取修改前的整行（OLD.*），这是记录“修改前值”的唯一可靠时机。错过这个时机，UPDATE 执行后 OLD 就不可访问了。
-
BEFORE UPDATE是唯一能读取完整OLD行的触发器类型；AFTER UPDATE只能读NEW，无法回溯原始值 - 若表有主键（强烈建议），应把
OLD.id或其他唯一标识作为审计日志的关联字段 - 避免在触发器里做耗时操作（如写文件、调外部 API），否则会拖慢主事务；只做轻量 INSERT 到日志表
- 注意字符集和 collation：如果日志表字段与源表不一致，
OLD.col_name插入时可能隐式转换失败，报Incorrect string value
PostgreSQL 中用 ROW() + jsonb_build_object 构造前后快照
PostgreSQL 不支持像 MySQL 那样直接引用 OLD.* 为一行值，必须显式列出字段或用函数构造结构化数据。最实用的方式是用 jsonb_build_object 把 OLD 和 NEW 各转成 JSONB，再存进日志表的 before_data / after_data 字段。
- 不要手写所有字段名拼接 JSON —— 易漏、难维护；用
jsonb_build_object('id', OLD.id, 'name', OLD.name, ...)虽啰嗦但可控 - 更健壮的做法是结合
hstore或to_jsonb(OLD.*)::jsonb，但需确保表中无大对象（bytea、xml）或不支持 JSONB 序列化的类型 - 触发器函数里别用
RAISE NOTICE，它不会阻止执行，但会污染数据库日志；真要调试，改用INSERT INTO debug_log ... - 如果源表字段经常增减，建议把审计逻辑抽到通用函数里，用
pg_attribute动态查列名，但会显著增加复杂度和风险
审计日志表设计必须包含时间戳、操作类型和变更标记
只存 OLD 和 NEW 快照远远不够。没有上下文，你根本不知道这条日志对应哪次 UPDATE、谁发起的、是否成功、改了哪些字段。
- 至少要有：
table_name（被审计的表名）、operation（'UPDATE'/'INSERT'/'DELETE'）、row_id（主键值）、changed_at（NOW()，不是CURRENT_TIMESTAMP，后者在事务内不更新）、user_name（用current_user或session_user，注意权限隔离） - 强烈建议加
diff字段（jsonb类型），存字段级差异，例如{"email": {"old": "a@b.com", "new": "x@y.com"}}；可由触发器用简单 CASE 或外部函数生成，避免应用层解析全量快照 - 别把日志表和业务表放同一 schema 下；独立 schema（如
audit）+ 只读权限给业务角色，防止误删或注入 - 日志表不建外键——否则主表 DDL 会被锁死；靠应用或定时任务做一致性校验即可
触发器里不能依赖 application-level 用户信息
数据库触发器运行在服务端，完全不知道 HTTP 请求头、JWT 或 session ID。想记录“谁改的”，不能靠前端传参，得靠数据库会话上下文。
- MySQL：可用
USER()（含 host）或CURRENT_USER()（含权限匹配的账号），但若用连接池（如 ProxySQL），看到的可能是中间代理账号 - PostgreSQL：
current_user是权限角色，session_user是登录用户，current_setting('app.user_id', true)可配合SET LOCAL app.user_id = '123'使用，但要求应用层每次事务开始前显式设置 - Oracle / SQL Server 类似，都需应用配合传递上下文；纯靠触发器无法拿到真实业务用户 ID
- 如果审计要求严格到“某员工 A 修改了客户 B 的电话”，那必须在应用层把用户标识注入 SQL（如
UPDATE ... SET x=y WHERE id=z /* user: alice */），再用触发器解析注释——不推荐，脆弱且难审计
真正难的不是写触发器，而是让日志具备可追溯性：字段改没改、谁在什么时间点通过什么路径改的、改之前到底是什么值。这些信息分散在数据库会话、应用日志、监控链路里，单靠 BEFORE UPDATE 拿不到全貌。
