必须选after触发器，因其在操作提交后稳定获取new/old值，避免事务回滚导致日志无效；insert无old、delete无new，before易报错且值不可靠；审计表应按字段粒度记录，update需显式比对字段变更。
AFTER触发器是唯一可行选择
审计必须记录“已经发生的事实”，不是“用户打算做什么”。用BEFORE触发器会踩两个致命坑：一是INSERT时OLD根本不存在，二是事务还没提交，若后续回滚，日志就成垃圾数据。只有AFTER INSERT、AFTER UPDATE、AFTER DELETE能保证NEW和OLD值已稳定落库、自增主键已生成、事务上下文完整。
常见错误现象：BEFORE INSERT里读OLD.id报错；BEFORE UPDATE里记录的值被后续语句覆盖；事务回滚后审计表里多出一堆无效记录。
-
AFTER INSERT：只读NEW.*，OLD不可用 -
AFTER UPDATE：OLD.col和NEW.col都可用，且是最终写入磁盘的值 -
AFTER DELETE：只读OLD.*，外键级联删除时OLD仍完整
审计表字段必须按字段粒度拆分
别把整行数据塞进一个old_data或new_data JSON 字段——查起来慢、没法索引、做不了字段级统计。审计的核心是“谁在什么时候改了哪一列、从什么值变成什么值”，不是备份。
推荐最小结构（以user_audit为例）：
CREATE TABLE user_audit (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
table_name VARCHAR(64) NOT NULL,
row_id BIGINT NOT NULL,
column_name VARCHAR(64) NOT NULL,
operation_type ENUM('INSERT','UPDATE','DELETE') NOT NULL,
old_value TEXT,
new_value TEXT,
change_time DATETIME DEFAULT CURRENT_TIMESTAMP,
changed_by VARCHAR(128)
);
-
row_id必须是原表主键值，类型要匹配（INT 就用BIGINT，UUID 就用VARCHAR(36)），别直接存字符串化 UUID 后丢掉排序和关联能力 -
changed_by别依赖USER()，它返回的是连接账号（如app@10.0.1.5）；应在应用层执行SET @current_user_id = '123'，再在触发器里读@current_user_id - 禁用外键、禁用对
old_value/new_value建索引——JSON 字段内容无法高效索引，维护开销远超收益
UPDATE触发器必须加字段比对
不加判断直接记录，一次UPDATE users SET updated_at = NOW()就会生成一条无意义日志，日志量爆炸。MySQL 触发器没“只记录变化字段”的默认逻辑，全靠你手动写条件。
正确写法示例（针对users表的name和email字段）：
DELIMITER $$
CREATE TRIGGER users_audit_update AFTER UPDATE ON users FOR EACH ROW
BEGIN
IF OLD.name != NEW.name THEN
INSERT INTO user_audit (table_name, row_id, column_name, operation_type, old_value, new_value, changed_by)
VALUES ('users', NEW.id, 'name', 'UPDATE', OLD.name, NEW.name, @current_user_id);
END IF;
IF OLD.email != NEW.email THEN
INSERT INTO user_audit (table_name, row_id, column_name, operation_type, old_value, new_value, changed_by)
VALUES ('users', NEW.id, 'email', 'UPDATE', OLD.email, NEW.email, @current_user_id);
END IF;
END$$
DELIMITER ;
- 注意
NULL比较要用IS NOT DISTINCT FROM或显式判空，OLD.email != NEW.email在任一为NULL时结果为NULL，导致条件失效 - 别在触发器里调用存储过程或
SELECT ... INTO——曾有人查关联表补用户名，结果主表更新卡住，连接池耗尽 -
AFTER UPDATE里禁止再UPDATE users，MySQL 直接报Can't update table 'users' in stored function/trigger
JSON_OBJECT()构造要防NULL陷阱
MySQL 5.7+ 的JSON_OBJECT('col', NEW.col)在col为NULL时会报错Invalid JSON text，不是忽略，是直接中断触发器执行，导致主DML失败。
安全做法是显式过滤NULL，或用IFNULL()兜底：
JSON_OBJECT('name', IFNULL(NEW.name, ''), 'email', IFNULL(NEW.email, ''))
- 如果字段允许
NULL且业务需要保留NULL语义，得用CASE WHEN构造带null关键字的 JSON 字符串，但更稳妥的做法是统一转空字符串或预设占位符 - 审计表的
old_value/new_value字段必须定义为JSON类型，否则JSON_OBJECT()会失败；用TEXT拼接易注入、难解析 - 时间字段务必用
NOW(3)，别用CURRENT_TIMESTAMP——语义模糊，部分 MySQL 版本行为不一致
CREATE TRIGGER，而是让每条日志都可查、可溯、不拖慢主流程。字段比对漏写、NULL没处理、changed_by取错源，这三处最容易在上线后才发现问题。
