mysql触发器不能直接用insert…select备份整行，因old/new是伪记录而非真实表，须逐字段引用；备份表结构须与原表严格一致，禁用auto_increment，推荐用before update并添加version_ts字段。
触发器里不能直接用 INSERT … SELECT 备份整行？
MySQL 触发器中确实可以读取 OLD 或 NEW 的字段值来保存历史，但很多人误以为能直接写 INSERT INTO history_table SELECT * FROM OLD —— 这语法根本不存在。OLD 和 NEW 不是真实表，只是伪记录，只能逐字段引用，比如 OLD.id、OLD.updated_at。
实操建议：
- 备份表结构必须和原表严格一致（字段名、类型、长度、是否允许 NULL），否则插入时会报
Column count doesn't match value count或类型转换错误 - 如果原表有自增主键，备份表的对应字段**不要设为 AUTO_INCREMENT**，否则
INSERT ... VALUES (OLD.id, ...)可能被忽略或冲突 - 强烈建议在备份表上加一个
version_ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP字段，显式记录备份时间，别依赖触发器里的NOW()赋值逻辑——它在事务回滚时仍会执行，造成时间戳“幽灵记录”
BEFORE UPDATE 触发器 vs AFTER UPDATE 触发器选哪个？
必须用 BEFORE UPDATE。因为你要存的是“修改前的状态”，而 AFTER UPDATE 里 OLD 已不可用（已被新值覆盖），且此时原行已更新，再查原表可能拿到新值，导致备份错乱。
常见错误现象：
- 用了
AFTER UPDATE却还试图INSERT INTO backup SELECT * FROM original WHERE id = OLD.id—— 如果并发更新同一行，可能查到别的事务刚写入的新值 - 没加事务隔离控制，在
READ COMMITTED下，AFTER触发器中查表可能看到中间态，备份内容不一致 -
BEFORE UPDATE中若对NEW做了修改（如自动更新updated_at），这些修改不影响OLD，所以备份仍是原始旧值，这是正确行为
如何避免触发器递归导致备份表也被触发？
如果备份表也定义了同名触发器（比如都叫 trg_user_update_backup），而你在备份表上执行 INSERT，就可能意外触发它，形成无限递归，最终报错 Too many levels of nesting for triggers。
解决方法只有两个，且必须同时做：
- 备份表**不定义任何触发器**——这是最干净的做法，确保它纯粹是只读归档容器
- 在原表触发器里，显式排除对备份表的操作影响：不需要额外判断，只要备份表没触发器，就天然免疫；但如果你用存储过程封装插入逻辑，务必确认该过程内部没隐式操作原表或其他带触发器的表
- 检查 MySQL 配置：
show variables like 'max_sp_recursion_depth';默认是 0（不限制），但递归真正发生时靠的是触发器链，不是存储过程深度，所以关掉无关配置没用，关键还是结构隔离
INSERT IGNORE 或 ON DUPLICATE KEY UPDATE 能用在备份里吗？
不能滥用。备份的核心诉求是“留痕”，不是“去重”。如果原表主键变更（比如 UPDATE SET id = 100 WHERE id = 99），你用 INSERT IGNORE 可能把旧 id=99 和新 id=100 都压进同一行，丢失版本信息。
正确做法：
- 备份表主键应设为复合主键，例如
(id, version_ts)或加自增backup_id作为主键，确保每次修改都生成新行 - 如果担心重复插入（比如业务层重试导致同一更新被发两次），可在触发器里加简单判重：
IF OLD.updated_at != NEW.updated_at THEN ... INSERT ... END IF;，但注意这仅防时间戳驱动的更新，不适用于所有场景 - 别用
REPLACE INTO—— 它本质是 DELETE + INSERT，在备份场景下等于主动删历史，极其危险
备份逻辑看似简单，但真正上线时最容易栽在字段类型隐式转换、备份表主键设计缺失、以及误把备份表当普通表加了触发器这三件事上。尤其是字段长度不一致（比如原表 VARCHAR(255)，备份表建成了 VARCHAR(100)），MySQL 默认截断不报错，历史数据就静默损坏了。
