AFTER UPDATE触发器确保仅提交成功的变更写入审计表，避免回滚导致脏数据；需用NOW()记录操作时间，显式存储action_time等字段，通过会话变量获取操作人，大表慎用以防性能问题。
触发器里用 AFTER UPDATE 而不是 BEFORE UPDATE
记录修改历史的关键是捕获“改完之后”的真实值，同时保留旧值做对比。用 BEFORE UPDATE 时，NEW 值虽可读，但事务若回滚，这条审计日志就成了脏数据；而 AFTER UPDATE 能确保只有成功提交的变更才写入审计表。
常见错误是把 OLD 和 NEW 混用错位置，比如把 OLD.updated_at 当成修改前时间，其实它只是原字段值，未必是上次更新时间——真正要记录的是这次操作发生的时间，得用 NOW() 或 CURRENT_TIMESTAMP。
-
AFTER UPDATE触发器中，OLD.*是修改前快照，NEW.*是修改后结果 - 审计表必须显式存
action_time字段，不能复用业务表的updated_at - 避免在触发器里调用函数（如
UUID()、SLEEP()），可能拖慢主表 DML 性能
审计表字段设计：别直接复制业务表结构
审计表不是业务表的镜像。冗余所有字段既浪费空间，又让查询和维护变重。重点只存三类信息：谁改的、改了哪行、改成了什么样。
典型漏掉的是操作上下文字段，比如 operated_by（用户ID）、client_ip、user_agent——这些没法从触发器自动获取，得靠应用层传入临时表或会话变量。
- 必有字段：
id（自增主键）、table_name（字符串，如'users'）、row_id（被修改行的主键值）、action（'UPDATE'）、action_time（DATETIME(6)精度更准） - 差异存储推荐用
JSON字段（MySQL 5.7+）存{ "email": ["old@example.com", "new@example.com"] }，比拆成几十个old_xxx/new_xxx字段灵活 - 索引要建在
(table_name, row_id, action_time)上，否则按业务ID查历史时全表扫
触发器里怎么安全拿到操作人信息
MySQL 触发器无法直接访问应用层的登录用户或 HTTP 请求头，USER() 返回的是数据库连接账户（通常是 'app@10.0.1.%'），对审计没意义。
可行做法是应用在执行 UPDATE 前，先设一个会话变量：SET @audit_user_id = 123;，然后触发器里读 @audit_user_id。但要注意变量生命周期仅限当前连接，且需应用严格配对设置与清理。
- 不建议用
SYSTEM_USER()或CURRENT_USER()替代操作人，它们反映的是权限账户，不是业务用户 - 如果用连接池（如 HikariCP），必须开启
useUnicode=true&characterEncoding=utf8并确认连接未被复用导致变量污染 - 触发器中应加判空：
IF @audit_user_id IS NOT NULL THEN ... END IF;，避免因应用漏设导致审计字段为NULL
大表上加触发器的性能雷区
单次 UPDATE 影响 10 万行？触发器会执行 10 万次插入——这比原 SQL 还慢。线上表超过 50 万行，就得警惕触发器带来的锁竞争和 binlog 膨胀。
更隐蔽的问题是：触发器报错会导致整个 UPDATE 回滚，而错误信息只显示“Trigger xxx failed”，不提示具体哪行出问题，排查成本高。
- 测试阶段务必用
EXPLAIN FORMAT=TREE看 UPDATE 执行计划，确认没因触发器引入隐式全表扫描 - 审计表引擎必须用
INNODB（支持事务），别用ARCHIVE或MYISAM，否则主表事务失败时审计数据可能残留 - 高频更新场景下，考虑用消息队列异步落库（如改用应用层发 Kafka 日志），而非强依赖触发器同步写
最常被忽略的一点：触发器不会记录 TRUNCATE TABLE 或 DROP 操作，这类 DDL 审计得靠 MySQL 的 general_log 或企业版 Audit Plugin，触发器对此完全无感。
