必须用 before update 而不是 after，因为 before 能稳定获取事务开始时的 old 值和即将写入的 new 值；after 在高并发下受 mvcc 影响可能读到被覆盖的中间状态，导致审计日志错乱，且无法回滚。
直接用 BEFORE UPDATE 触发器，配合 OLD. 和 NEW. 显式比对字段值，是唯一可靠、可回滚、能覆盖 NULL 场景的方案。AFTER 触发器在高并发下会读到被覆盖的中间值，日志必然错乱。
为什么必须用 BEFORE UPDATE 而不是 AFTER
MySQL 触发器中只有 BEFORE UPDATE 能稳定拿到更新前后的原始值：OLD.phone 是事务开始时的值，NEW.phone 是即将写入的新值。而 AFTER UPDATE 执行时，行记录可能已被其他并发事务修改，OLD/NEW 语义失效——这不是文档没写清楚，是 InnoDB MVCC 和触发器执行时机共同导致的实际行为。
- 常见错误现象：AFTER 里写
INSERT INTO audit_log VALUES(OLD.id, OLD.phone, NEW.phone)，结果日志里出现“旧值=新值”或“旧值=NULL 但实际不为空” - INSERT 和 DELETE 只能分别用
BEFORE INSERT（只读NEW）和BEFORE DELETE（只读OLD），不存在“前后对比”逻辑 - 想记录“从空到有”，必须显式判断：
OLD.phone IS NULL AND NEW.phone IS NOT NULL，不能依赖!=—— NULL != '123' 返回 NULL 而非 TRUE
怎么高效判断多个敏感字段是否变更
别为每个字段写独立 IF 块，维护成本高且易漏字段。用 UNION ALL 子查询把所有敏感字段的变更条件收拢到一个结果集，再统一插入审计表。
- 关键点：用
IS NOT DISTINCT FROM替代!=，它能正确处理NULL比较（例如NULL IS NOT DISTINCT FROM NULL返回 TRUE） - 示例片段（监控
phone和email）：INSERT INTO audit_log (table_name, record_id, field_name, old_value, new_value, updated_at) SELECT 'users', NEW.id, field_name, old_val, new_val, NOW() FROM ( SELECT 'phone', OLD.phone, NEW.phone WHERE OLD.phone IS NOT DISTINCT FROM NEW.phone = FALSE UNION ALL SELECT 'email', OLD.email, NEW.email WHERE OLD.email IS NOT DISTINCT FROM NEW.email = FALSE ) AS changes;
- 避免在触发器里调用函数（如
JSON_OBJECT()）或跨库写入——MySQL 触发器不支持事务嵌套，出错会导致主更新失败并回滚整个事务
审计表结构设计最容易踩的三个坑
审计表不是原表镜像，强耦合等于埋雷。最常翻车的是照搬原表结构、加外键、或给 JSON 字段建索引。
-
pk_value必须定义为VARCHAR(255)，不能照抄原表主键类型——万一原表主键是UUID或复合键（如(user_id, org_id)），数值型字段根本存不下 - 绝对不要加外键约束：
ALTER TABLE audit_log ADD FOREIGN KEY (record_id) REFERENCES users(id)。删原表时会因外键依赖失败，迁移或清理直接卡死 -
changed_fields用JSON类型存变更快照（如{"phone": ["138...", "139..."]}），但别给这列建索引——MySQL 对 JSON 字段内容无法高效索引，WHERE JSON_CONTAINS() 查询极慢 - 必须建联合索引：
INDEX idx_table_record_time (table_name, record_id, updated_at)，否则查某条记录的历史变更要全表扫描
触发器性能和权限的硬限制
触发器是同步阻塞执行的，每行更新都会卡住主 SQL 直到日志写完。没有异步、没有队列、不能降级。
- 单次 UPDATE 影响 1000 行？触发器就执行 1000 次 INSERT，IO 和锁开销直接翻倍。线上高频更新表慎用，优先考虑
ROW格式 binlog + 外部 CDC 工具 - 触发器内不能用
USER()获取应用层账号——它返回的是连接用户（如'app@10.0.1.5'），不是应用传的业务账号。真要记操作人，得由应用层把账号作为字段传入（如UPDATE users SET phone='...', operator='admin_user' WHERE id=1） - 触发器代码里别写
SELECT ... FROM another_db.audit_config——跨库查询在某些 MySQL 8.0.33+ 版本会报错ERROR 1356 (HY000): View 'another_db.audit_config' references invalid table(s) or column(s)，因为触发器上下文不支持跨库元数据解析
真正难的不是写触发器语法，而是判断哪些字段算“敏感”、哪些变更值得记、以及当触发器因磁盘满或权限不足失败时，你能否第一时间发现——它不会抛异常给应用，只会静默让主 SQL 失败，而错误日志里只有一行 ERROR 1146 (42S02): Table 'audit_log' doesn't exist，藏得很深。
