必须用AFTER UPDATE而非BEFORE，因只有更新真实生效后，OLD和NEW值才稳定可读且事务一致；BEFORE下若事务回滚，审计记录即成脏数据。
触发器里用 AFTER UPDATE 而不是 BEFORE UPDATE
记录历史版本的核心是“修改已发生”，所以必须在更新完成之后捕获新旧值。用 BEFORE UPDATE 时，NEW 和 OLD 虽然可用，但事务还没提交，若后续回滚，你存的历史记录就成了脏数据。而 AFTER UPDATE 确保只有真实生效的变更才会写入日志表。
常见错误是误以为 BEFORE 更“及时”，结果导致历史表和主表状态不一致，尤其在批量更新或事务中问题更隐蔽。
-
OLD和NEW在AFTER UPDATE触发器中完全可用，别被文档误导 - 主键字段必须显式列出在
INSERT INTO history_table语句中，不能依赖* - 如果主表有自增主键，历史表通常要额外加一个时间戳字段（如
updated_at）或版本号字段来区分同一行的多次变更
历史表结构要包含原始主键 + 变更元数据
只复制主表字段到历史表是不够的。缺少上下文，你根本分不清哪条是哪次改的、谁改的、为什么改。最简可行结构至少包括：
- 所有原表主键字段（用于关联溯源）
-
updated_at：DATETIME(6)或TIMESTAMP(6)，带微秒精度，避免并发更新时时间戳重复 -
operation：ENUM('INSERT','UPDATE','DELETE')或VARCHAR(10)，方便统一审计 -
updated_by（可选但推荐）：从USER()或应用层传入的用户标识字段获取，不能只靠触发器自动填CURRENT_USER()—— 它返回的是数据库连接用户，不是业务操作人
示例建表语句片段：
CREATE TABLE user_history (
id INT NOT NULL,
name VARCHAR(100),
email VARCHAR(255),
updated_at DATETIME(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6),
operation ENUM('INSERT','UPDATE','DELETE') NOT NULL,
updated_by VARCHAR(100),
PRIMARY KEY (id, updated_at)
);
触发器体里避免调用不确定函数或外部依赖
MySQL 触发器运行在事务上下文中，且禁止执行某些操作（如显式开启新事务、调用存储过程里的 COMMIT）。最容易踩的坑是误用以下内容：
-
NOW()或CURRENT_TIMESTAMP多次调用可能在同个触发器内返回不同值（尤其高并发下），应只调用一次并赋给变量 - 不要在触发器里查其他表做条件判断（比如“只有当用户等级 > 5 才记录”），这会拖慢主表更新，还可能引发死锁
- 避免调用自定义函数，除非它被明确定义为
DETERMINISTIC且无副作用；否则 MySQL 可能拒绝创建触发器 - 不能在触发器里对同一张表做 DML 操作（比如在
user的AFTER UPDATE里再UPDATE user），会报错ERROR 1442 (HY000)
上线前必须测试并发更新和事务回滚场景
单条 UPDATE 测试通过不代表生产安全。真正出问题的往往是：
- 两个事务同时更新同一行：历史表会不会多出一条？主键冲突？
- 事务中 UPDATE 后又 ROLLBACK：历史表里的记录是否残留？（答案是会——这是
AFTER触发器的固有限制） - 批量 UPDATE（如
UPDATE user SET status=1 WHERE type='temp'）：触发器会为每一行单独执行一次，性能是否可接受？
应对方法很实在：把历史表主键设计成 (original_id, updated_at) 组合，避免并发插入冲突；对关键业务表，考虑用应用层异步写历史（如发 MQ），而不是强依赖触发器——后者在数据一致性要求极高、吞吐量大的场景下，反而成了瓶颈点。
