不能，触发器无法真正恢复被覆盖的字段值；它仅能在UPDATE前（BEFORE）或后（AFTER）保存旧值到审计表，后续需手动或通过脚本查询还原，且恢复逻辑必须脱离触发器单独执行。
触发器能“恢复”被覆盖的字段值吗？不能，但可以存档
SQL 触发器本身无法回滚或撤销已执行的 UPDATE 操作，也不能把新值“换回”旧值——它没记忆、不干预、只响应。所谓“恢复”，实际是靠触发器在覆盖发生前（BEFORE UPDATE）或后（AFTER UPDATE）把旧值保存到另一张表或字段里，后续靠人工或逻辑查表还原。真要自动回填，得额外写逻辑（比如用存储过程封装更新+回查），触发器只是守门人，不是时光机。
BEFORE UPDATE 触发器保存旧值最稳妥
这是最常用也最安全的方式：在新值写入前，把 OLD.column_name 抓出来存档。相比 AFTER，它避免了并发更新导致旧值被二次覆盖的风险，也不依赖事务未提交时的临时状态。
常见做法：
- 建一张审计表，如
user_profile_audit，含user_id、field_name、old_value、updated_at、updated_by（如果能拿到） - 在触发器里显式插入：
INSERT INTO user_profile_audit (user_id, field_name, old_value, updated_at) VALUES (OLD.id, 'email', OLD.email, NOW());
- 注意：不要在
BEFORE UPDATE里改NEW.column来“阻止覆盖”，除非你真想拦截——这属于业务校验，不是恢复 - MySQL 中
OLD在BEFORE和AFTER都可用；PostgreSQL 同理，但语法用OLD.*引用更明确
直接在原表加 last_email_before_update 字段可行但不推荐
有人会想：不如每次更新前把旧值写进本表一个备份字段？技术上可以，但会污染主表结构、增加索引负担、引发语义混乱（比如该字段对新记录为空，查询时需反复判空）。
更现实的取舍：
- 只对极少数关键字段（如
status、balance）做单字段快照，且明确生命周期（比如保留最近 3 次变更） - 用 JSON 字段暂存历史，如
update_history JSON，写入json_array_append(update_history, '$', json_object('field', 'email', 'old', OLD.email, 'at', NOW()))—— 但检索和索引支持弱，仅适合低频回溯 - 别让触发器承担清理逻辑（如自动删老快照），容易拖慢主更新；交给定时任务或应用层异步处理
恢复操作必须脱离触发器单独执行
触发器只负责“记下来”，不负责“还回去”。真要恢复某个用户的邮箱，得手动或通过脚本查审计表，再发一条 UPDATE：
UPDATE users
SET email = (SELECT old_value FROM user_profile_audit
WHERE user_id = 123 AND field_name = 'email'
ORDER BY updated_at DESC LIMIT 1)
WHERE id = 123;
这里容易踩的坑：
- 没加
ORDER BY ... LIMIT 1可能返回多行，导致 MySQL 报错Subquery returns more than 1 row - 审计表没建复合索引（
(user_id, field_name, updated_at)），大表下查询极慢 - 恢复时没检查事务隔离级别，可能读到未提交的中间状态（尤其用
READ UNCOMMITTED） - 别在触发器里调用这种恢复语句——会引发递归触发或死锁
真正难的从来不是怎么存旧值，而是怎么定义“该恢复哪一次”：按时间？按操作人？按变更幅度？这些规则不在 SQL 层，而在业务逻辑里。
