MySQL原生仅靠触发器可实现字段级审计，但需用BEFORE触发器安全获取OLD/NEW值，避免JSON序列化失败、事务断裂等问题，并通过条件过滤、异步落库等优化性能。
想在MySQL里实现字段级别的变更审计，追踪“哪个字段被改了、从什么值变成什么值”，纯原生的方案其实就一个：触发器。这听起来简单直接，但真要用起来，坑可不少。性能抖动、JSON序列化失败、事务一致性断裂，甚至触发器自己把自己给连环触发了——这些都不是危言耸听。
BEFORE UPDATE 触发器里怎么安全取 old_data 和 new_data
先说一个核心原则：必须用 BEFORE 触发器，而不是 AFTER。为什么呢？在 AFTER 阶段，虽然 NEW.id 这类字段已经确定，但 OLD 值在 INSERT 操作中根本不可用，而且你也没法在触发器里回滚主表的操作了。而 BEFORE 阶段就灵活得多，OLD 和 NEW 值都能拿到，甚至还能主动抛错中止操作。
- OLD.字段名 只在
UPDATE和DELETE操作中有效。如果你在INSERT的触发器里引用它，会直接报错：Unknown column 'OLD.id' in 'field list'。 - NEW.字段名 在
INSERT和UPDATE中都可用。但要注意，在UPDATE中，如果某个字段没有出现在SET子句里，那么NEW.字段名的值就等于OLD.字段名的值，也就是“没变化”。 - 别直接用
SELECT JSON_OBJECT('id', OLD.id, 'name', OLD.name)这种写法来拼装JSON。当字段很多、或者包含NULL、BLOB类型时，很容易出错。更稳妥的做法是使用JSON_OBJECTAGG()配合CONVERT(... USING utf8mb4)进行显式转码。 - 对于敏感字段，比如
ssn（社会安全号）或password_hash，建议单独判断。只在IF OLD.ssn != NEW.ssn THEN ... END IF;这样的条件块里写入审计日志，可以有效避免日志数据过度膨胀。
audit_log 表设计要防 JSON 写入失败和查询慢
用 JSON 类型来存 old_data 和 new_data，看起来很方便，但背后有隐患。MySQL 5.7+ 对JSON字段的索引支持其实有限，而且像 INSERT INTO audit_log VALUES (..., JSON_OBJECT(...)) 这样的语句，如果字段里包含二进制数据或者超长文本，可能会被静默截断，甚至直接报 Invalid JSON text 错误。
- 一个更可靠的方案是：把
old_data和new_data拆成两个MEDIUMTEXT字段。在写入前，先用JSON_VALID()函数校验一下，如果JSON不合法，就降级存储为'{"error":"invalid_json"}'这样的标记。 record_id字段的设计也别太随意。如果主表的主键是BIGINT，直接存数字字符串就行；如果是UUID，确保入库前已经统一格式，比如用LOWER(REPLACE(uuid, '-', ''))处理一下。- 索引是关键。务必创建一个复合索引，例如：
CREATE INDEX idx_audit_table_action_time ON audit_log (table_name, action_type, change_timestamp);。这样，查询某张表最近的10条更新记录时，速度才能有保障。 - 还有一个常见的误区：别在触发器里调用
CURRENT_USER()来获取操作人。它返回的是“数据库连接用户”，而不是“应用层真正的操作者”。要实现精准溯源，得靠应用层在执行业务SQL时，显式传递一个参数（比如SET @audit_user = 'api-service-23';），然后在触发器里读取这个@audit_user变量。
触发器性能崩了怎么办：跳过非敏感字段、批量合并、异步落库
想象一下，每一行 UPDATE 操作都触发一次完整的JSON构造和审计表 INSERT，当每秒请求量（QPS）上千时，审计表的I/O很容易成为瓶颈，甚至反过来拖垮主业务表的写入性能。
- 最直接的优化是在触发器开头加条件过滤。例如：
IF NOT (OLD.email NEW.email OR OLD.phone NEW.phone OR OLD.sec_level NEW.sec_level) THEN LEA VE proc_label; END IF;。这样一来，只有你真正关心的敏感字段发生变化时，才会触发审计逻辑。 - 别在触发器里做太复杂的逻辑。比如，调用存储过程去解析JSON差异、或者关联查询用户表来补全操作人姓名。这些工作，都应该移到应用层，或者交给CDC（变更数据捕获）这类后置服务去处理。
- 终极的解决方案是异步化。触发器只负责向一个轻量的中间层（比如写入
mysql.general_log，或者推送到Redis List）发送一条简单的消息。然后由外部的消费者服务异步解析这些消息，再批量落库。这样，主事务就完全不受审计流程的影响了。 - 监控必不可少。重点关注这两个指标：
SHOW STATUS LIKE 'Com_stmt_execute';和innodb_rows_inserted的增长是否同步。如果后者（插入行数）的增长速度远高于前者（语句执行数），那很可能就是审计插入正在消耗大量资源。
最后，必须提醒一点：触发器有一个天然的盲区。它无法捕获像 UPDATE ... SET col = col + 1 这类自计算更新中的原始值差异。因为binlog里只记录最终结果。如果你的审计要求必须还原“+1之前的值”，那就必须在应用层先执行一次 SELECT 获取旧值，再执行 UPDATE。或者，放弃触发器方案，改用ROW格式的binlog，并配合像Debezium这样的工具来解析变更流。这才是关键所在。
