MySQL触发器中不能用SELECT...INTO写快照表，须用INSERT...SELECT或显式字段列表；推荐BEFORE UPDATE+BEFORE DELETE组合捕获变更与删除；快照表需建(original_id, snapshot_time)复合索引并启用COMPRESSED行格式。
触发器里不能用 SELECT ... INTO 写快照表
MySQL 触发器中执行 SELECT ... INTO 会报错 ERROR 1327 (42000): Undeclared variable，因为触发器作用域不支持直接声明并赋值变量用于后续 INSERT。快照本质是“某时刻的行副本”，必须靠 INSERT ... SELECT 或显式字段列表完成写入。
- 正确做法：在快照表结构与原表一致的前提下，用
INSERT INTO snapshot_table SELECT *, NOW() FROM OLD（BEFORE DELETE）或NEW（BEFORE UPDATE） - 别试图在触发器里拼接动态表名或调用存储过程做快照——触发器不支持
PREPARE/EXECUTE，也不允许修改当前正在操作的表 - 时间戳字段要提前在快照表里建好，类型用
DATETIME(6)比TIMESTAMP更稳妥，避免时区隐式转换干扰
AFTER INSERT 和 BEFORE UPDATE 哪个更适合存快照
取决于你要捕获的是“新增前状态”还是“变更后状态”。快照不是日志，它要能还原出某一行在某个时间点的完整样子，所以关键看业务语义：
-
BEFORE UPDATE：适合记录“修改前快照”，比如审计谁把价格从 99 改成了 199，快照里存的是旧值 -
AFTER INSERT：适合记录“首次创建快照”，但注意：如果插入后立刻被删，而你没配BEFORE DELETE，那这条快照就成唯一凭证了 - 最常用组合是
BEFORE UPDATE+BEFORE DELETE，覆盖变更和删除场景；AFTER INSERT可选，除非你需要保留所有历史版本（含初始值）
快照表主键和索引设计直接影响查询性能
快照表通常比原表大得多，且查询常按 original_id + snapshot_time 组合过滤，但很多人忽略这点，只加了个自增 id 主键就完事。
- 必须给原表主键字段（如
user_id）加普通索引，否则按用户查历史快照会全表扫 - 复合索引优先建
(original_id, snapshot_time)，而不是反过来——因为多数查询先定人再查时间范围 - 别在快照表上加唯一约束（如
UNIQUE(original_id, snapshot_time)），UPDATE 可能在毫秒级内多次发生，导致冲突 - 快照表建议用
ROW_FORMAT=COMPRESSED+KEY_BLOCK_SIZE=8，尤其当文本字段多时，能省 30%+ 存储
触发器无法处理批量操作和事务回滚后的清理
这是最容易被忽略的硬伤：当你执行 DELETE FROM orders WHERE status = 'canceled'，哪怕影响 10 万行，触发器也只对每行调用一次 BEFORE DELETE，但如果你在触发器里写了耗时逻辑（比如写磁盘、调外部 API），整个事务会卡住；更麻烦的是——事务一旦 ROLLBACK，触发器写的快照数据不会自动撤回。
- 快照表必须和原表在同一个库、同一个引擎（推荐
InnoDB），否则无法保证原子性 - 禁止在触发器里写跨库语句，MySQL 不允许
TRIGGER操作其他数据库的表 - 线上环境务必测试长事务下的触发器堆积效应：开个事务删 1000 行但不提交，快照表会先写 1000 条，且不可见，直到事务结束
事情说清了就结束。触发器做快照看着简单，真正压到生产上，性能拐点、事务可见性、索引误配这三处一碰就出问题。
