能，但必须用AFTER触发器：AFTER UPDATE/DELETE用OLD.备份修改前快照，AFTER INSERT用NEW.；BEFORE触发器无法实现有效审计，且可能引发递归更新错误。
触发器能自动备份单条记录吗？能，但必须用 AFTER 触发器
不能用 BEFORE 触发器做备份——它在原记录更新前执行，OLD 和 NEW 都可用，但此时原表数据还没改，你“备份”的其实是未修改状态，起不到审计/回滚作用。真正要存修改前快照，得靠 AFTER UPDATE 或 AFTER DELETE 触发器，且必须把 OLD 行显式插入到备份表中。
常见错误是写成 BEFORE UPDATE 并试图 INSERT 到备份表，结果备份的是“即将被覆盖的值”，而非“已被覆盖的历史”。更隐蔽的问题是：如果触发器里又去 UPDATE 原表（比如更新一个 updated_at 字段），可能引发递归触发，MySQL 默认会报错 Can't update table 't' in stored function/trigger because it is already used by statement which invoked this stored function/trigger。
-
AFTER INSERT：备份新增行，用NEW.* -
AFTER UPDATE：通常备份OLD.*（修改前状态），也可按需同时存NEW.* -
AFTER DELETE：只能用OLD.*，且必须在此刻完成备份，删完就没了
备份表结构必须严格兼容 OLD/NEW 的字段和类型
如果原表是 users(id INT PRIMARY KEY, name VARCHAR(50), email VARCHAR(100), updated_at TIMESTAMP)，备份表不能只建 id 和 name——少字段会导致 INSERT 失败；也不能把 email 定义成 VARCHAR(20)——超长截断不报错但丢数据；更不能漏掉允许 NULL 的字段却定义为 NOT NULL。
最稳妥的做法是：用 CREATE TABLE users_bak LIKE users 创建结构一致的表，再额外加几个审计字段：
ALTER TABLE users_bak
ADD COLUMN backup_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
ADD COLUMN op_type ENUM('INSERT', 'UPDATE', 'DELETE') NOT NULL,
ADD COLUMN backup_id BIGINT AUTO_INCREMENT PRIMARY KEY FIRST;
注意：PRIMARY KEY 和 AUTO_INCREMENT 必须显式处理，原表的主键在备份表里只是普通字段，不参与约束。
触发器体里不能有事务控制语句（如 START TRANSACTION）
MySQL 触发器运行在父语句的事务上下文中，你不能、也不该在触发器里写 COMMIT 或 ROLLBACK——这会直接报错 Trigger's execution context does not allow this statement。备份是否成功，完全取决于父事务是否提交：父 SQL 成功，备份也落盘；父 SQL 回滚，备份 INSERT 也会一起回滚。
这意味着：如果你希望“即使主表更新失败，备份也要留下痕迹”，触发器做不到。必须换方案，比如应用层双写，或用 binlog 解析+异步投递。
- 触发器内可安全使用
INSERT INTO ... SELECT、VALUES(OLD.*) - 禁止出现
SELECT ... FOR UPDATE、LOCK TABLES等锁表操作 - 避免在触发器里调用存储函数，尤其那些含 SQL 的——嵌套太深易死锁或超时
性能隐患：高频更新表上建触发器 = 给每次 DML 加 IO 延迟
每执行一次 UPDATE users SET name='x' WHERE id=1，触发器就会同步执行一次 INSERT INTO users_bak SELECT ... FROM OLD。磁盘写入无法跳过，QPS 上千时，备份表写入可能成为瓶颈，甚至拖慢主业务。
这不是理论风险：某次线上事故就是 orders 表加了 AFTER UPDATE 触发器备份，促销期间订单更新密集，备份表日志刷盘延迟飙升，连带主表响应从 20ms 涨到 800ms。
- 非核心表、低频变更（如配置表、员工档案）适合用触发器备份
- 订单、消息、计数类高频表，应改用应用层异步写、或开启 binlog + 用 Debezium 同步
- 务必给备份表加索引：至少在
backup_at和op_type上建联合索引，否则查历史版本极慢
真正难的不是语法，是想清楚“这条记录为什么值得备份”——是合规要求？还是真会用来回滚？如果只是怕误操作，mysqldump --single-transaction 配合定时快照更轻量；如果要逐行追踪，触发器只是起点，后面还得接清理策略（比如只保留 90 天）、查询封装（避免业务代码直查备份表）。
